Monday, October 22, 2012

The Difference between Interaction Design and User Experience

In this era of an incredibly fast and evoluting industry of usability it is only normal to find difficulties in defining the boundaries of the various industry roles and technical terms used. In this article my intention is to describe the difference between interaction design and user experience.

Via US Booth: User Interface Design, Getting the Basics Right...

Posted by admin on 10/22 at 12:15 PM
Posted in:
(0) TrackbacksPermalink

Saturday, October 20, 2012

EE Multi-Language Sites (revisited) - part 2

Previously we cleaned-up the URLs, now we make them dynamic

We’ll presume the native language, English, is the root language, with Spanish and Russian as alternative languages. 

In this example, the web root is at /var/www/.

Walkthrough:

1) Create directories for the languages using their ISO name and copy the EE index.php from the root into each of the language directories

/var/www/ru for Russian
/var/www/es for Spanish

2) Edit the index.php file in the root directory. In the CUSTOM CONFIG VALUES section, add this:

//Set default language
$assign_to_config['global_vars']['language'"en";
$assign_to_config['global_vars']['base_url'"http://sitename.com/"

3) Edit the index.php in each language subdirectory (ru, es), adding an extra period to the SYSTEM PATH variable, so that:

$system_path '.system'

in the /ru/ directory becomes:

$system_path '..system'

4) In the CUSTOM CONFIG VALUES section, add this and extend the URL to redirect through the current language directory. EG, in the Russian /ru/ directory:

//Set default language
$assign_to_config['global_vars']['language'"ru";
$assign_to_config['global_vars']['base_url'"http://sitename.com/ru/"

Do this for each of the languages.

5) Finally, add a custom .htaccess to each of the language directories, to handle removing index.php from each subsection. Again, for the Russian /ru/ directory:

RewriteEngine on
RewriteCond 
$!^(index\.php[NC]
RewriteRule 
^(.*)$ /ru/index.php/$1 [L] 

Do this for each of the languages, and that’s basically it.

On logging back into the Control Panel, you’ll be greeted with a notice:

One or more core files have been altered:
/var/www/index.php
/var/www/ru/index.php
/var/www/es/index.php

Accept the changes and get on with your life. Next we set up the multi-language variables…

Posted by admin on 10/20 at 07:48 AM
Posted in:
(0) TrackbacksPermalink

Friday, October 19, 2012

EE Multi-Language Sites (revisited) - part 1

A while ago I did a how-to on putting a multi-language site together for EE 1.x using the Multisite Module from PutYourLightsOn. It’s a good module and Ben’s support has been excellent, but for EE 2.0, I’ve found a way to roll my own…

I’ll do this in series of posts, but let’s dive in first with setup. The plan is to:

  • Clean up the URLs to remove index.php from it

  • Set up the system so the title is the filename

  • Set-up system variables so language is selected by resolving the path

  • So if the path is http://www.shortcuts.nl/article/title I’ll get the default language (English). If its http://www.shortcuts.nl/nl/article/title I’ll get the other language translation - the plan is to have Spanish and Russian languages. Them’s the rules…

    We’re going to presume a few things:

  • UNIX-based hosting

  • Apache 2.x or later with mod_rewrite installed and enabled

  • ExpressionEngine 2.2 or later

  • 1) we create a .htaccess file in the docroot of your website. This is based on the ExpressionEngine.com example:

    <IfModule mod_rewrite.c>
            
    RewriteEngine On
     
            
    # Removes index.php
            
    RewriteCond $!\.(gif|jpe?g|png)$ [NC]
            RewriteCond 
    %{REQUEST_FILENAME} !-f
            RewriteCond 
    %{REQUEST_FILENAME} !-d
            RewriteRule 
    ^(.*)$ /index.php/$1 [L]
     
            
    # If 404s, "No Input File" or every URL returns the same thing
            # make it /index.php?/$1 above (add the question mark)
    </IfModule

    2) In the Control Panel (Admin > GENERAL CONFIGURATION) set the name of the site’s index page to blank (empty the field) and Submit.

    3) Test. Test the site’s links to see that index.php isn’t required in the url. A good practice is to use a template set-up through the Pages module with a fixed url (/blog/ for instance) and then see if the page can be reached.

    Errors:
    Some common problems include links returning 404s, a “No Input File Specified” error, or all links returning the same content. This can often be the case with hosts that require you to force query strings. If this happens, try adding a question mark as described in the .htaccess comments above.

    Other common errors, often also generating a 403 Forbidden, is the setup for Apache and whether it allows .htaccess the rights to rewrite the URL. Check your Apache configuration for the Directory command. Compare it to the example below:

    <Directory "/var/www/siteroot/">
        
    Options Indexes MultiViews Includes
        Options FollowSymLinks
        AllowOverride All
        Order allow
    ,deny
        Allow from all
    </Directory

    Two very important lines to watch for:

    Options FollowSymLinks   (usually missing)
    AllowOverride All       (often set wrongly to NONE)

    Mac local configurations suffer from this by default - this is why 403s occur when you try to crawl your Sites folder.

    Once resolved, your URLs should be cruft-free.  Move on now to making your paths dynamic...

    Posted by admin on 10/19 at 01:22 AM
    Posted in:
    (0) TrackbacksPermalink

    Monday, October 15, 2012

    10 steps to securing your Wordpress install…

    Using Wordpress? According to Forbes, one out of every 6 websites on the Internet is powered by WordPress (nearly 60 million in all), with 100,000 more popping up each day, and Wordpress.com currently hosts over 56 million of those blogs. The odds are likely that you’re expecting the site hosting service to take care of your security issues. If so, the real odds aren’t in your favor.

    I routinely upgrade companies who have outgrown Wordpress or have been hacked (to my preferred platform, ExpressionEngine, just so you’re aware of my biases). I really don’t like shifting platforms just because you’ve been hacked, but quite often people and companies take a view that “software is just a solution” without realising that no solution is ever permanent - everything needs to be minded and maintained. Because the promise was “a solution”, the promise seems to have been broken and it poisons any future relationship the software has with the customer. Chalk it up to managing expectations, but for many, many people the promise is often more important than the delivery.

    So it’s amazing to discover how many sites don’t even make an effort to do the basics. Tighten permissions, move and rename known resources, mask dangerous accounts. I do think we rely too much on hosting companies, and many of those 58 million affected by those Wordpress and GoDaddy outages might agree, but there is no two ways about it: You need to secure your Wordpress environment, so here are 10 steps to making your installation as secure as possible. (Admittedly the last step has 21 bullet points, but at least it’s thorough…) Let’s keep the script kiddies at bay.

    Via antjanus.com...

    Posted by admin on 10/15 at 09:55 AM
    Posted in:
    (0) TrackbacksPermalink

    Wednesday, March 07, 2012

    Wordpress - It’s a Victim *and* an Enabler too!

    My timing was excellent about my last post. Less than a week after I wrote about WordPress’s sloppy security, there’s news of a malware injector that invades WordPress sites and used them to infect site visitors.

    From The Verge

    A piece of malware that masquerades as antivirus software has been found on 200,000 web pages or almost 30,000 unique sites, says computer security group Websense. The exploit, which mostly affects sites built with WordPress, places a short piece of injected code at the bottom of a page…When a user loads the page, they’re redirected to a page in the .rr.nu top-level domain that mimics a Windows security scan, then asks them to download a malicious program to supposedly clear viruses from their computer. It’s a scam that’s been running in various forms for years, and Websense says it’s been tracking this particular threat for several months.

    They’ve got some info on the header and such - if you use that system it’s worth looking at.

    PS: We’re on Expression Engine. You’re safe.

    Via The Verge...

    Posted by admin on 03/07 at 06:58 PM
    Posted in: Gadgetry   IT notes  
    (0) TrackbacksPermalink
    Page 2 of 23 pages  <  1 2 3 4 >  Last »