Thursday

Differences between PHP4 and PHP5

Here's a quick overview of what has changed between PH4 and PHP5. PHP5 for the most part is backwards compatible with PHP4, but there are a couple key changes that might break your PHP4 script in a PHP5 environment. If you aren't already, I stronly suggest you start developing for PHP5. Many hosts these days offer a PHP5 environment, or a dual PHP4/PHP5 setup so you should be fine on that end. Using all of these new features is worth even a moderate amount of trouble you might go through finding a new host!

Note: Some of the features listed below are only in PHP5.2 and above.

Object ModelThe new OOP features in PHP5 is probably the one thing that everyone knows for sure about. Out of all the new features, these are the ones that are talked about most!

Passed by ReferenceThis is an important change. In PHP4, everything was passed by value, including objects. This has changed in PHP5 -- all objects are now passed by reference.

PHP Code:
$joe = new Person();$joe->sex 'male';
$betty $joe;$betty->sex 'female';

echo 
$joe->sex// Will be 'female'  
The above code fragment was common in PHP4. If you needed to duplicate an object, you simply copied it by assigning it to another variable. But in PHP5 you must use the new clone keyword.

Note that this also means you can stop using the reference operator (&). It was common practice to pass your objects around using the & operator to get around the annoying pass-by-value functionality in PHP4.

Class Constants and Static Methods/Properties
You can now create class constants that act much the same was as define()'ed constants, but are contained within a class definition and accessed with the :: operator.

Static methods and properties are also available. When you declare a class member as static, then it makes that member accessible (through the :: operator) without an instance. (Note this means within methods, the $this variable is not available)

Visibility
Class methods and properties now have visibility. PHP has 3 levels of visibility:
  1. Public is the most visible, making methods accessible to everyone and properties readable and writable by everyone.
  2. Protected makes members accessible to the class itself and any subclasses as well as any parent classes.
  3. Private makes members only available to the class itself.
Unified Constructors and DestructorsPHP5 introduces a new unified constructor/destructor names. In PHP4, a constructor was simply a method that had the same name as the class itself. This caused some headaches since if you changed the name of the class, you would have to go through and change every occurrence of that name.

In PHP5, all constructors are named __construct(). That is, the word construct prefixed by two underscores. Other then this name change, a constructor works the same way.

Also, the newly added __destruct() (destruct prefixed by two underscores) allows you to write code that will be executed when the object is destroyed.

Abstract ClassesPHP5 lets you declare a class as abstract. An abstract class cannot itself be instantiated, it is purely used to define a model where other classes extend. You must declare a class abstract if it contains any abstract methods. Any methods marked as abstract must be defined within any classes that extend the class. Note that you can also include full method definitions within an abstract class along with any abstract methods.

InterfacesPHP5 introduces interfaces to help you design common APIs. An interface defines the methods a class must implement. Note that all the methods defined in an interface must be public. An interface is not designed as a blueprint for classes, but just a way to standardize a common API.

The one big advantage to using interfaces is that a class can implement any number of them. You can still only extend on parent class, but you can implement an unlimited number of interfaces.

Magic Methods
There are a number of "magic methods" that add an assortment to functionality to your classes. Note that PHP reserves the naming of methods prefixed with a double-underscore. Never name any of your methods with this naming scheme!

Some magic methods to take note of are __call, __get, __set and __toString. These are the ones I find most useful.

Finality
You can now use the final keyword to indicate that a method cannot be overridden by a child. You can also declare an entire class as final which prevents it from having any children at all.

The __autoload FunctionUsing a specially named function, __autoload (there's that double-underscore again!), you can automatically load object files when PHP encounters a class that hasn't been defined yet. Instead of large chunks of include's at the top of your scripts, you can define a simple autoload function to include them automatically.

PHP Code:
function __autoload($class_name) {
     require_once 
"./includes/classes/$class_name.inc.php";
}  
Note you can change the autoload function or even add multiple autoload functions using spl_autoload_register and related functions.

Standard PHP LibraryPHP now includes a bunch of functionality to solve common problems in the so-named SPL. There's a lot of cool stuff in there, check it out!

For example, we can finally create classes that can be accessed like arrays by implementing the ArrayAccess interface. If we implement the Iterator interface, we can even let our classes work in situations like the foreach construct.


Miscellaneous Features

Type Hinting
PHP5 introduces limited type hinting. This means you can enforce what kind of variables are passed to functions or class methods. The drawback is that (at this time), it will only work for classes or arrays -- so no other scalar types like integers or strings.

To add a type hint to a parameter, you specify the name of the class before the $. Beware that when you specify a class name, the type will be satisfied with all of its subclasses as well.

PHP Code:
function echo_user(User $user) {
    echo 
$user->getUsername();
}  
If the passed parameter is not User (or a subclass of User), then PHP will throw a fatal error.

ExceptionsPHP finally introduces exceptions! An exception is basically an error. By using an exception however, you gain more control the simple trigger_error notices we were stuck with before.

An exception is just an object. When an error occurs, you throw an exception. When an exception is thrown, the rest of the PHP code following will not be executed. When you are about to perform something "risky", surround your code with a tryblock. If an exception is thrown, then your following catch block is there to intercept the error and handle it accordingly. If there is no catch block, a fatal error occurs.

PHP Code:
try {
    
$cache->write();
} catch (
AccessDeniedException $e) {
    die(
'Could not write the cache, access denied.');
} catch (
Exception $e) {
   die(
'An unknown error occurred: ' $e->getMessage());
}  
E_STRICT Error Level
There is a new error level defined as E_STRICT (value 2048). It is not included in E_ALL, if you wish to use this new level you must specify it explicitly. E_STRICT will notify you when you use depreciated code. I suggest you enable this level so you can always stay on top of things.

Foreach Construct and By-Reference Value
The foreach construct now lets you define the 'value' as a reference instead of a copy. Though I would suggest against using this feature, as it can cause some problems if you aren't careful:

PHP Code:
foreach($array as $k => &$v) {
    
// Nice and easy, no working with $array[$k] anymore
    
$v htmlentities($v);
}
// But be careful, this will have an unexpected result because
// $v will still be a reference to the last element of the $array array
foreach($another_array as $k => $v) {

}  


New Functions

PHP5 introduces a slew of new functions. You can get a list of them from the PHP Manual.

New Extensions
PHP5 also introduces new default extensions.
  • SimpleXML for easy processing of XML data
  • DOM and XSL extensions are available for a much improved XML-consuming experience. A breath of fresh air after using DOMXML for PHP4!
  • PDO for working with databases. An excellent OO interface for interacting with your database.
  • Hash gives you access to a ton of hash functions if you need more then the usual md5 or sha1.
Compatibility IssuesThe PHP manual has a list of changes that will affect backwards compatibility. You should definately read through that page, but here is are three issues I have found particularly tiresome:
  • array_merge() will now give you warnings if any of the parameters are not arrays. In PHP4, you could get away with merging non-arrays with arrays (and the items would just be added if they were say, a string). Of course it was bad practice to do this to being with, but it can cause headaches if you don't know about it.
  • As discussed above, objects are now passed by references. If you want to copy a object, make sure to use the clonekeyword.
  • get_*() now return names as they were defined. If a class was called MyTestClass, then get_class() will return that -- case sensitive! In PHP4, they were always returned in lowercase.

Usability of RIA with Flex

User Interface Design Principles

1. The Client Is Not The User
The client may think she knows what the user wants, but she cannot. This is because the client is not the user.
This brings me to the second principle:
2. Don't Give The Client What She Thinks The User Wants
If the client does not know what the user wants and you give her what she is asking for, you are doing her a disservice. You will ultimately be delivering an application that does not meet user's needs. Your client may initially be happy that you have given her exactly what she asked for but will she remain happy when the product is rejected by users?
I have seen too many designers and developers who are aware of these two principles but proceed to reach the wrong conclusion from it. Namely, that they know the user better. Which brings us to our next principle, which is, simply:
3. You Do Not Know What Your User Wants
You may be a user interface designer or developer with many years of experience but you do not know what users want. Which users? Those specific users who will be using the current application that you are building. Why? Because every application is unique. You may have built similar applications but, unless you have built exactly this application before, you do not know what the users of this application want.
So, who does know what your users want?
4. Only Users Know What Users Want
It's a basic concept but one that is alien to much of our industry. Only users of your application will know what works and what doesn't. It's surreal that, given this, most of us in our industry go out of our ways to delay asking them what they think of our applications. This brings me to the most imporant principle of all:
5. Test Early, Test Often, Then Test Again
Usability testing is not rocket science. In fact, it's quite a simple recipe:
Ingredients:
  1. Two rooms
  2. One or more representative users
  3. A computer running your application
  4. A usability tester
  5. A video camera (no tape)
  6. A TV screen
Take two rooms and place a computer running your application in one of them. In that room, place a representative user and a usability tester who will ask the user to perform various tasks in your application. Place a camera in the room to relay your user's actions to your design/development team who should be watching from the second room. (Ideally, having the rooms next to each other means that you don't have to run too much cable between the two but you can just as easily use wireless technologies or even broadcast the feed over the Internet to a development team across the globe.)
Leave to simmer then repeat.
Notice that you do not even need to record the test. If you do, chances are those tapes will become paperweights like most artifacts that are created during development. Remember: Agile is good.
Doing usability testing does not involve a large upfront financial investment. You can put together the above setup for around $1,000 these days. What it does involve, however, is buy-in to a User-Centered Product Development (UCPD) approach from the highest levels at both your and your client's organization.
Following a UCPD approach involves capturing measureable Usability Requirements alongside your Functional Requirements. You will have to set aside time to carry out usability testing at every iteration in your development process. You cannot do this without a budget. And you won't have a budget unless you have buy-in at the highest levels.
The above principles are perhaps the most important ones as they will determine your development process and your development process will largely decide whether your project succeeds (is accepted by your users) or fails (is rejected by your users.)
Alongside these process-related principles are design principles. These do not, in any way, replace testing. They are intended to give you a good starting point when designing your user interface, before you go to your users and say, "What do you think?"
6. Talk One Language
There should only ever be a single term or phrase used to refer to any given item in the application. An item here may refer to a concept, a business function or task or even a widget or individual interface element. You will find that the use of a metaphor for the project, as advocated by eXtreme Programming (XP), will ease this task tremendously.
7. Respect User Effort
Try to limit the user's physical toil while using the application. Repetitive Strain Injuries (RSI) are a fact of life today and we, as application designers, have to accept responsibility for the ergonomics of our applications.
8. Make difficult decisions
It is your job as the user interface designer to layer the user interface and make important decisions about its organization. Don't leave these decisions to the user just because it makes your life easier. If your application has a huge preferences section, treat this as a Design Smell and review the design to see if you have left decisions that you can make to the user.
9. Let The User Work
Users must be able to perform their most frequent, most important tasks without any resistance. For an SMS Messaging application, for example, this would include reading, replying to and forwarding messages and quickly checking the various mailboxes.
10. Prevent, Don't Scold
Whenever possible the UI should prevent the user from making a mistake instead of alerting the user to the mistake after the fact. This must be achieved without the UI getting in the way of the user.
11. Give Sufficient Feedback
The UI should give the user sufficient feedback for user actions. (This ties in nicely with Steve Krugs "Don't Make Me Think" philosophy: The user should never have to think "did that work?") Related to Don't Lose The User.
12. Show, Don't Tell
Although this may seem to contradict the Give Sufficient Feedback principle, it is actually meant to compliment it. Whenever possible, meaningful visual cues (when appropriate to the audience) should be chosen instead of lengthy textual descriptions. This can also pertain to actually teaching a user to do something in an application by showing them.
13. Don't Lose The User
The UI should protect the user's sense of spatial positioning. The user should never feel "lost" within the application.
14. Don't Sell What You Can't Deliver
Users must not be given Graphical User Interface (GUI) expectations that cannot be met (or can only be partially met) within a Web User Interface (WUI). Whenever OS or GUI expectations are set, they must be fully met. That said, the application must try and meet OS expectations as much as possible, especially for ergonomic features such as keyboard shortcuts and navigation but also for expected auxiliary helpers such as tooltips.
Don't Sell What You Can't Deliver is the main principle behind why Adobe chose to create a new component style called Halo in Flash and Flex instead of trying unsuccessfully to emulate either the Windows XP or Mac OS X look and feel.
15. Don't Keep Them Waiting
The application must perform fast enough to be considered usable within the given engineering limits for the application.
16. Innocent Until Proven Guilty
The user should be warned about a validation error on a control only if they have had a chance to interact with that control. (In other words, you should not perform validation on controls that are in their initial state and initially display a form full of validation errors.) Similarly, resetting a form should remove all validation errors.
17. Usability Approach to Accessibility
There is a trend I am noticing in our field that I find very worrisome and it concerns accessibility. Many people appear to be on a quest for the Magic Button of Accesibility (MBA). This is how an MBA works in an ideal world:
You gather usability requirements for your application for a given target audience. This target audience involves people with good eyesight, hearing, and motor control. Based on the usability requirements for this specific audience, you expand resources in designing a good user experience for this specific audience. You then spend further resources in developing your application, going back to users within this specific audience to get their feedback and to alter your design accordingly. Finally, right before you deliver your application, you press the Magic Button of Accessibility.
The Magic Button Accessibility magically makes the experience of your application as good for various other audiences. These include people who have various levels of sight, hearing, and motor control. Isn't it amazing that the MBA can transform a carefully crafted experience for a single audience into equally pleasurable experiences for many other audiences.
Unfortunately, the Magic Button of Accessibility doesn't exist because it cannot exist.
The MBA is an extreme example of the check-the-checkbox mentality to accessibility that is pravalent in our field today. I call this Checkbox Accessibility: For the most part, we do not really care what sort of experience users with accessibility requirements will have with our applications as long as we can check a checkbox on some form that says that our application is compliant with a set of rules.
If we can run our applications through a program that checks for this, all the better. After all, software is cheap compared to devoting extra time to design and develop an equally good experience for various other audiences. Checkbox Accessiblity is head-and-shoulders better than no accessibility but it does not guarantee a good experience for users with accessibility requirements.
The other approach to accessibiltiy is to see it as usability with different audiences. In other words, you cannot make your application truly accessible for users with disabilities without designing for those users. I call this the Usability Approach to Accessibility.
Having a usability approach to accessibility means that you have to gather usability requirements for disabled users just like you do for users without disabilities. You have to usability test with disabled users. And you have to realize that "disabled users" doesn't refer to a single audience but to multiple audiences, including those with accessibility requirements in sight, hearing and motor function.
Of course, just like usability with an audience of non-disabled users, usability for disabled users costs time and money and will require buy-in at the highest levels of your organization. If you are serious about accessibility, however, anything less is just not good enough.
These are general points of advice that can apply to any application. Based on these overall guidelines, the following are examples of high-level design decisions that were taken and applied in Opal. Keep in mind that Opal was developed in Flash MX but the issues are the same regardless of whether you are building an application in MTASC/SWFMill/FlashDevelop, Flash 8, Flash 9, Flex 1.5 or Flex 2. Each of those tools and technologies provides different features, components, programming models and development workflows but the end result, regardless of which technologies are used, is always evaluated by your users.

Principles applied: examples

The SMS Character Count gives users sufficient feedback and the message textbox allows users to see a whole SMS message without scrolling.Respect User Effort: eliminating scrolling
The message preview textbox displays a full SMS message without scrolling. It meant that sacrifices had to be made with some of the other form elements on the Message Tabs. Reading an SMS message is both an important and frequently-performed task and so the other sacrifices were justified (also see Make difficult decisions.)
Give Sufficient Feedback: SMS character count
A custom SMS character count widget shows users exactly how many characters they have left before they need to send a message as two or more SMS messages. This is an especially important piece of information for users as they are charged for each SMS message sent.
Prevent Don't Scold: Form validations
All forms implement client-side validation. Submit buttons (such as "Send Message" or "Add Contact") gray out until the form passes client-side validation. This does not remove the need for server-side validation and all form submissions are validated server-side for correctness and security before being processed. Client-side validation exists solely to improve the user experience and does not provide any security whatsoever.
The Send Business Card screen doesn't let users hit the send button before they have filled in all required fields.
Let The User Work: Mailbox Tabs and Message Action Tabs
The Mailbox Tabs allow users to quickly switch mailboxes.A composite tab-based interface exposes the critical, frequent tasks to users. Mailbox Tabs give users single-click access to their mailboxes. They also expose context-sensitive message actions for each mailbox. Users can immediately see the actions that they can perform on a message in a given mailbox tab.
Implementing a context-sensitive menu that hides possible actions until it is triggered would have ranked at the opposite end of the usability spectrum and been ignored by most new users.
Show, Don't Tell: Menu Bar and Tool Bar as teaching methods for migrating Outlook users.
Menu Bar and Tool Bar allow Outlook users to migrate easily to Opal.A menu bar and tool bar remind users of the ones in Outlook without creating operating system specific expectations.
The menu and tool bars implement Show, Don't Tell.
When an Outlook user first changes to a given mailbox using the menu or tool bar, the Mailbox tab animates to the chosen mail box, thereby showing the user that they could also have clicked on the tab (although the tab control is a well-known GUI component in its own right.) The same goes for when the user selects a Message Action (eg. Reply).
Don't Lose The User and Don't Sell What You Can't Deliver: Screen-based RIAs vs. Multiple-Window-based RIAs.
Opal uses a screen-based approach instead of a full window-based one so as not to confuse users with unfulfilled operating system expectations.It is very important to note the differences between Graphical User Interfaces (as used by desktop applications such as Outlook) and Web User Interfaces (as used by Rich Internet Applications such as Opal). It is equally important to manage client's expectations as to the limitations of Web User Interfaces, even those termed "Rich" and developed using Flash.
The greatest difference between a WUI and a GUI is usually the most overlooked: WUI applications run from within a GUI application which, in turn, runs inside a window-based operating system. Past usability studies have shown that especially beginning users have problems with the concept of multiple windows, preferring usually to keep a single window up at a time. Even in multitasking operating systems like Windows XP or OS X, novice users sometimes prefer to start up a single application, shut it down and start another application and so on. The perceived complexity of the system is heightened when the user is confronted with an interface (an RIA such as Opal) within a GUI application (the web browser) that itself contains windows.
Firstly, we rob our novice user of the comforts of his single window existence. Secondly, the new windowing system works in a different way and contains its own rules and limits. It is thus important to implement a screen-based interface in RIAs so that you Don't Lose The User and Don't Sell What You Can't Deliver.
Even if an RIA developer takes pains to develop a Multi-Window Interface that mimics a certain dominant OS, the interface is still being presented to the user in the document area of a GUI application (the web browser). This is contrary to OS expectations wherein users expect not to see windows within documents. Perhaps this is one area where application browsers such as Central will have an impact on user expectations. It remains, however, that the only way a multi-window interface can provide a high-level of usability in an RIA is if the application can run in its own OS window and not as a document within a web browser and thus access the windowing abilities of whatever OS it happens to be running on. As this is currently not a possibility with Flash, we decided to go with a screen-based system in the application.
Although modal pop-ups are sparingly used due to issues of screen real-estate and Outlook migration expectations, users are visually shown that these dialog boxes are modal screens via the graying out of lower screens. Although this removes the OS expectations surrounding non-modal multiple-window interfaces, the graphic similarity of the dialog screens to windows still leads certain users in testing to attempt to move windows around.
Don't Keep Them Waiting: The name of the game is performance.
If there was one issue we kept running into during development, it was performance. Flash is not the fastest kid on the block and it is possible to run into issues when client's expectations are not managed as to the limitations of RIAs. Although RIAs can recreate a lot of the desktop application experience from within a web application, there are limits.
Flash 9 and ActionScript 3 have made great strides in performance and it is important to keep in mind that this project was being published for the Flash 6 player.
A detail from the custom Grid component.One issue, for example, was that the speed of the setSize() method on the Macromedia DRK Data Grid was resulting in unacceptable redraw times when the application was resized. This resulted in a very risky two-weeks in which I wrote a completely new Data Grid component that implemented the DRK Data Grid interface and could be plug-and-play replaced into application. The resulting Data Grid offered a 10x performance boost and brought redraw rates back within acceptable limits.
I hope that this article has challenged how you think about usability and accessibility and that you will find it to be a useful resource in designing and developing web applications. As always, I value your feedback so please feel free to leave a comment and share your thoughts.




Usability for Rich Internet Applications

After struggling for years to design Internet applications around the limitations of HTML, I have been very excited by the recent release of a range of Internet applications with increased richness and interactivity.
The key challenge in designing part-page updates is making sure people see them.
Rich Internet applications (RIAs) can provide opportunities to design much better user experiences. They can be faster, more engaging and much more usable. However, this improvement is not without its downside—RIAs are much more difficult to design than the previous generation of page-based applications. The richer interaction requires a better understanding of users and of human-computer interaction (HCI). Although there is a lot of HCI material and research available, it can be difficult to determine how it applies to this new environment.
In this article, I provide some practical tips for designing usable RIAs, based on fundamental principles of HCI.

What’s an RIA?

According to the Wikipedia, RIAs are “a cross between Web applications and traditional desktop applications, transferring some of the processing to the client end.”
The key difference between RIAs and other Internet applications is the amount of interaction in the interface. In a traditional page-based Internet application, interaction is limited to a small set of standard controls such as checkboxes, radio buttons, form fields and buttons. This severely limits our ability to create usable and engaging applications, and most Internet applications have been clumsier and more difficult to use than their desktop counterparts. An RIA can use a wider (and hopefully better) range of controls to improve users’ interaction with the interface, allowing efficient interactions, better error management, feedback and overall user experience.
Some of my favorite sites with RIA-style interfaces include:
Many are built with Flash or using Ajax techniques.
The key features of these applications include:
  • The user interacts directly with page elements (inline editing, drag-and-drop, panning a map)
  • Part of a page is updated (instead of reloading)
  • More detailed information is available on the same page (instead of on a new page)
  • Feedback, confirmation and error messages are provided within the page
These rich features are also those that provide the most challenge for designers who wish to ensure applications are highly usable.

Challenge #1: Deciding How Much Richness to Add

When designing RIAs, it is tempting to design many new features that add a lot of richness. Don’t give in to this temptation! Regular folks who have been using the Internet for a number of years are comfortable with the existing page-based model and limited interactivity, as clumsy as it may appear to designers and developers. It takes time for people to adapt to new approaches. It will be some time before conventions emerge and users are comfortable with the new generation of applications. Go slowly, adding richness where it significantly improves usability, and relying on traditional models where these better suit your user group.
Good user research (and a focus on users throughout the design process) and regular usability testing will help you determine how much richness is appropriate at a point in time.

Challenge #2: Interactive Page Elements

One way to add richness to your application is to allow users to directly interact with page elements: editing text inline, dragging and dropping graphic elements, panning a map.
A primary challenge is to communicate what can be done with page elements and how to use new controls. People must be able to identify that a control exists and easily determine how to use it.
In The Design of Everyday Things, Don Norman popularized the idea of perceived affordance (the perceived and actual properties of a thing that determine just how the thing could possibly be used). For example, the original 3D button has great perceived affordance. By highlighting the top and shadowing the bottom, people perceive it as popping out of the screen and easily understand that it can be pushed by clicking.
One way is to use controls that mimic things people are familiar with from the physical world, such as the slider on Fidelity Labs Mortgage Search.
a slider
Another is to change the appearance of the element or show the controls when the mouse hovers over it, showing what can be done without cluttering the interface. Backpack uses this to indicate elements that can be edited or deleted.
hover effects in backpack
In addition to ensuring your controls have good perceived affordance, you should:
  • Remember how valuable a demonstration can be. In the initial stages of a new interface, use a small in-page tutorial video to show the interaction.
  • Ensure controls and interaction models are used consistently throughout the interface and are similar to other sites that your users visit. This helps people easily learn what to do and build on previous experiences.

Challenge #3: Refreshing Part of the Page

There is significant advantage in updating part of the page instead of refreshing it or opening a new page. It allows us to create faster applications, improve feedback to the user and manage errors better. Error management and feedback are critical to improving usability, but it’s particularly difficult to do with the page-based model. Users have become accustomed to taking an action (such as clicking a link), waiting for the action to complete, and checking the result of the action.
The key challenge in designing part-page updates is making sure people see them. We can use what we know about visual attention and visual processing to ensure people will see that part of the page has been updated:
  • Visual attention is attracted by movement and high color contrast (that’s why bright, animated banner ads are so distracting—our eyes are constantly pulled toward them). We can use this to our advantage and draw the eye to the updated part of the page.
  • When we take an action such as clicking a button, our eyes remain fixed on that point for a short time, then release to look somewhere else. By making sure the change occurs quickly and as close as possible to where they are looking, we can ensure the eye is drawn to the appropriate place.
  • Visual attention can only be focused on one thing at a time. Make one update at a time, and don’t use high-contrast, moving images elsewhere on the page. 37 Signals were one of the first to do this, popularizing the yellow fade technique. Odeo provides effective feedback by using color, movement and placing it right where the user is looking:
button in odeo

Challenge #4: Breaking the Page Model

As we interact with the world, we develop a mental model of how things work. Most users have developed a mental model of the Web based on pages—every click takes you to a new page. Clicking on the back button takes you to the previous page. This is a strong mental model, and is reasonably accurate for the majority of content-rich sites. Users will continue to apply their page-based mental model to RIAs unless they can clearly identify that the RIA uses a different model.
The first part of this challenge is to think very hard about where to use individual pages and where to use in-page richness. Think about the entire interaction of your application and break it up appropriately. Don’t try to put everything into one “page” just because you can.
One factor is the likely use of the back button. Consider when people may need to go “back”—this will give you clues about where to use pages. Don’t disable the back button, reducing users’ control of their situation.
Another challenge is how to visually express the difference between pages and in-page changes. You may need to design different visual navigation models so people can identify when they are getting a new page. It is likely that some new navigation methods will emerge over time.
Google Reader manages pages very poorly. The buttons in its traditional top navigation bar (Home, Your Subscriptions, etc.) imply navigation to individual pages, but actually change the content in the body of the page. When I first used Google Reader, I frequently tried to use the back button to return to the home page but was thrown right out to the last page I visited before reaching Google Reader. This was so frustrating, I stopped using it.
google reader
In contrast, Yahoo! News manages pages and in-page updates well. It has traditional top tabbed navigation to individual pages and in-page panels that change based on the news source:
yahoo's top navigation
yahoo's inpage navigation

Review Usability Best Practices

Don’t forget the usability basics. Jakob Nielsen’s Ten Usability Heuristics are as relevant now as they were in 1999. I stress this because I looked at the Flex showcase recently, and it looks like many of the applications are not built with these best practices in mind.

1. Visibility of system status (Feedback)

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
feedback_button
1.0 BaseCamp by 37signals
The upload button is enabled, until clicked. Then it is replaced with a progress indicator until the file has finished uploading
feedback_progress
1.1 Picnik
Progress message and indicator shows while the application loads
feedback_message
1.2 Tick
A feedback message is displayed when an action is performed
feedback_inline
1.3 Windows Live Account
Password strength is shown as the password is entered

2. Match between system and the real world (METAPHOR)

The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
metaphor_library
2.0 iTunes
Organized as a library that contains your media library: music, movies, shows, audibooks. Beneath the Library is the Store where you can buy more media to put in your Library.
metaphor_mindmap
2.1 Mindomo
The branches and hierarchy of a mind map can be easily reorganized visually in a non-linear manner. An outline would never work, but this matches the paradigm exactly.

3. User control and freedom (NAVIGATION)

Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Supports undo and redo and a clear way to navigate.
navigation_search
3.0 CollabFinder
Search is easy to open, enter info, execute or cancel.
navigation_selected
3.1 Wufoo
Clearly marks where the person is and where they can go by showing the selection in each menu
navigation_cell_editor
3.2 Pages (Apple’s Word Processing Product)
Cell editing shows row and column ids, and the cells used in the equation. The equation can be saved or canceled.
navigation_undo_redo
3.3 Balsamiq
Undo and Redo buttons are available in the toolbar, and can also be accessed with the standard keyboard shortcuts

4. Consistency and standards (CONSISTENCY)

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
consistency_naming
4.0 Gmail
When Gmail was designed, they based the organizational folders on the same ones used in client email applications: Inbox, Drafts, Sent Mail.
consistency_toolbars
4.1 Microsoft Office
Word, Excel, and PowerPoint all use the same style toolbar with the same primary menu options: Home, Insert, Page Layout… Consistency results in efficiency and perceived intuitiveness.

5. Error prevention (PREVENTION)

Even better than good error messages is a careful design, which prevents a problem from occurring in the first place.
prevention_disable
5.0 Yammer
Disables the update button after it is clicked, so the person cannot update the post twice by accident
prevention_buttons
5.1 Example from “Web form Design:Filling in the Blanks” by Luke W.
Make the primary action prominent with a larger click area. Cancel and secondary actions are just shown as links
prevention_auto_suggest
5.2 Google Auto Recommend
The auto recommend feature cuts down on mis-spellings
prevention_focus
5.2 Wikpedia
Auto focus on input prevents a common source of frustration, typing only to realize nothing is displayed because the field did not have focus

6. Recognition rather than recall (MEMORY)

Minimize the user’s memory load. Make objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
memory_type_ahead
6.0 Quanta IDE
Type ahead for coding in a development environment
memory_font
6.1 Keynote
Previews the fonts you can pick from, instead of just the font name

7. Flexibility and efficiency of use (EFFICIENCY)

Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
efficiency_shortcuts
7.0 OmniFocus
List of keyboard shortcuts and accelerators
efficiency_preview
7.1 Numbers- Apple’s Spreadsheet product
Previews common function results on the left when a column is selected, more efficient that clicking on an action in the toolbar

8. Aesthetic and minimalist design (DESIGN)

Dialogues should not contain information, which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. Visual layout should respect the principles of contrast, repetition, alignment, and proximity.
design_c_r_a_p
8.0 Kontain
Kontain’ search menu exemplifies the four principles of visual design:
Contrast: bold text is used for the two labels in the search
Repetition: the orange, blue, and green text match the media types
Alignment : strong left alignment of text, right aligned drop down
Proximity: a light rule is used to separate tags from the other options
design_alignment
8.1 Harvest
Sufficient padding and spacing keep this timesheet from being a visual nightmare. Header and footer rows, as well as the summary column use subtly different colors to indicate they are distinct from the content

9. Help users recognize, diagnose, and recover from errors (RECOVERY)

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
error_message
9.0 Digg
Provides immediate feedback with specific instructions
error_page
9.1 Humorous ‘ Page Not Found’ Error
Uses a funny image and copy, but provides viable alternatives (article listings and blog link) and a course of action (report it)

10. Help and documentation (Help)

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.
help_contextual
10.0 Picnik
Contextual help (this is an example of help in the ‘Collages’ module) tips in Picnik are clear and easy to navigate
help_video
10.1 GoodBarry
Embedded videos can be used to showcase features as well as get people started using the product
help_tip
10.2 Zenoss
Help tips are displayed on hover, answering the most likely questions about a field or instructions
help_button
10.3 BaseCamp by 37signals
Help opens a new browser window/tab with a full set of help resources: search, FAQ, video tutorials, customer forums

Interview with Dries Buytaert, Creator of Drupal By David Peterson | April 28, 2010 | Web Tech

Drupalcon San Francisco — last week, David Peterson (@davidseth) caught up with Dries Buytaert(@Dries), the creator of Drupal, to discuss where Drupal is heading, what challenges are ahead and what keeps him going.

Dries Buytaert: What do you want to talk about?

David Peterson: I wanted to talk about where you see the big shifts happening — touching on Tim O’Reilly’s keynote address where he talked about the future of devices and cloud data. Also, I was in the Warner Brothers Drupalcon session and they said the biggest problem they were facing is not music piracy. It’s actually the fragmented way that people access content. The website is no longer the focal point; it’s actually the Nintendo Wii’s, the Xbox, PlayStations and mobile phones. So with that in mind, where do you see things going and how will Drupal facilitate that?

DB: Right.

DP: So let’s start with a very basic question. When do you think a stable beta version of Drupal 7 might land?

DB: So, Drupal 7 has about a 100 critical bugs left as of this morning. So we’ll do a release when that number is zero. But, I don’t really know when that number will be zero. It’s really up to everybody in the community to help fix it.

If we do some analysis on the current big fix rate, looking at our history of successful bug fixing, it looks like it could be anywhere between early June (best case) and the end September (worst case).

DP: What about a beta release? Drupal 7 is in alpha right now, will there be a certain point that you were looking to release a stable beta?

DB: We’ve released the third alpha. There’ll be a beta when we feel the upgrade path works.

DP: Like the upgrade from CCK to the new Fields API?

DB: The upgrade path from Drupal 6 to Drupal 7.

DP: So essentially a core 6 to core 7 upgrade?

DB: Well, yes. CCK is no longer a part of Drupal 7 so a migration path has to include taking what was CCK and upgrading it to Fields. That’s what we are thinking right now. It’s still some thing which we need to discuss a little bit more because the CCK people actually think it might be better to keep the CCK update as a contributed module, for a little while, for technical reasons.

But the bigger picture of a Drupal 7 release, the big goal is to get the upgrade path to work in a way that everybody agrees with and then we’ll switch to beta releases.

DP: In your keynote you mentioned distributions as being a really important aspect of Drupal and a real point of differentiation. Why do you feel it’s such a driving part of what makes Drupal unique and how will that help the uptake of Drupal in the wider community?

DB: To answer the first question, which I think was why is it important, when I talk to people, usability is still the number one issue. And not just usability but, “Can Drupal do this?”, “Can Drupal do that?”, “How do I do this?”. There’s a lot of barriers to get people started, that starts with installation, module selection and usability. There’s all of these things and I think distributions are a great way to solve that. These are packaged solutions instead of a framework with a big box of building blocks.

DP: And a scary learning curve (laughs).

DB: So I think it helps with the learning curve which I think will help with Drupal’s growth. If we can remove some of those barriers with new distributions then I think Drupal will succeed in growing a lot more.

DP: Kind of along a similar vein, what do you think are Drupal’s biggest challenges in terms of the future? In your keynote, you mentioned WordPress is now moving towards a more open model along with Joomla and other systems. What challenges does Drupal face within a more homogeneous group?

DB: The big threat, sort of an ugly word, but is of course that if Joomla and WordPress are coming from the bottom up, if you will, then that could replace part of our install base. So that’s a threat. And I think distributions could help protect ourselves against that because it means distributions could do many of the things that WordPress does. Just to be clear, I’m not super competitive with WordPress or Joomla. I don’t want to come across as fearing those projects.

DP: Yeah. I suppose maybe “threat” was not the right word. It’s more like ‘how do you keep Drupal relevant in a world that’s homogenising?’

DB: My long term concern is staying relevant. How do we keep the level of agility and innovation and stuff that we have today that allow us to be leading edge and to be all the things that make us so successful.

DP: So what are you doing to address that? Currently, I guess it’s a great community, lots of contributions and things like that. But I mean one of the things you addressed in the keynote again is you want more people to give back. How are you going to maintain that Drupal will always be at the forefront? How do you do that?

DB: It’s very much a cultural thing. I don’t think there’s technical solutions to these problems. Just a desire that people have to be innovators and for the project to be state of the art compared to other projects, but also to maintain the way that we work. I’m not saying that we should adjust the way we work. We have to keep the project healthy, but keep our core values, our base principles that we have had for many, many years. But I think the ingredients are all there. I think everything works pretty well the way things have been working and so trying to stick with those I think is key.

As it grows it’s always easy to apply rules. Its one of those things that sometimes adding rules is much, much easier than removing rules, so once you’ve added a rule or a new process it’s very hard to get rid of it.

DP: Things are developing at a fast pace now. Facebook has just announced the Open Graph protocol, essentially it’s a protocol that enables integration of web pages into a graph, a social graph. And I know in the Boston Drupalcon you talked about that and you’ve been talking Linked Data and the Semantic Web multiple times since. In Monday’s keynote you again talked about Tim Berners-Lee’s Giant Global Graph. Previously it’s always been a bit more academic and a bit more techie, but I guess with Facebook’s rubber stamp this morning its finally getting real and exciting.

DB: Yeah, I haven’t seen it yet but it sounds exciting.

DP: I have just just barely read it myself (laughing).

In Tim O’Reilly’s keynote he talked about the future of the web in which the browser becomes less important but portable devices and inter-operating with the cloud becomes the dominant medium.

How is Drupal going to lead in the era where the web browser and the web interface is actually on the decline and the rise of the cloud and devices?

DB: Right. I think it’s putting more focus on import and export, web service APIs and those kinds of things instead of just HTML. In Drupal 7 there are some significant improvements. We are starting to make the HTML renderer basically abstract away from the system a little bit so that we make it easier to generate other formats like JSON, XML or whatever. So I think evolving that sort of to the next level where there is much more web service integration and things like RDF and RDFa will help.

DP: So in some ways I guess kind of treating a Drupal page more as a data layer rather than a traditional static HTML page. Something that could act like a possible layer in a transaction. Something like that?

DB: For example it’s sort of related — like in Drupal 6, we basically generated snippets of HTML and that’s how a page was generated. In Drupal 7 we still do the same thing but before we start generating all of those snippets we first build a big data object of the entire page. A big nested structure which is sort of like a page object. And that actually makes it very cool because you capture the structure of the page and can perform operations on the page.

Also, by capturing the annotations around a function we could automatically generate a web service API for that function. If we can do that for the functions as well as for data types then I think Drupal becomes super hackable in a good way (laughs). We can start using it as a mash-up platform, start doing all of these things.

DP: That sounds Great.

Microsoft’s announcement at Drupalcon of a native SQL Server driver for PHP was really cool. Are there any other tricks up Drupal’s sleeve? Are there any other things in the works or strategic partnering with these previously less then Open Source friendly groups?

DB: I know there’s a lot of companies looking at Drupal right now trying to figure out how they can leverage Drupal. Ultimately that’s what they want to do. I know Dreamweaver recently got a Drupal plugin I think from Adobe. It’s another small example of how big companies are starting to take notice of Drupal, starting to build software for it.

DP: What other areas of technology interest you? What excites you? What keeps your brain ticking to the next step?

DB: A lot of different things. A Drupal specific one for example, I think the next thing that we need to look at for the enterprise is staging. I spoke to a lot of enterprise customers and staging and configuration management is a problem that we need to solve. It’s a difficult problem but at the same time that’s sort of what makes me excited about it. It’s not like a small problem. It’s actually a big problem which could require some significant engineering potentially so that keeps me excited.

I think cloud computing and software as a service are exciting me. Not only from a technical point of view but also from a business model point of view. I think cloud computing and software as a service actually bring new monetization opportunities to open source which is something that we didn’t really have before. I mean, some people did it before but we’re starting to better understand the possibilities of cloud computing and open source and how we can leverage it to monetize open source project. Which I think is healthy. Because we can still give everything back, but at the same time organisations will be able to make money off of open source which I think is very important for a project to be successful.

I think a good example of this is distributions in Drupal. It’s really cool. It would be really great to have many of them. And I think we’ve solved many, but not all, of the technical problems. And I think there’s going to be revisions of the technology that we’ve built in distributions. But I think the big challenge is still the business model around distribution. We need to figure out how people can make money by building distributions, because building a distribution is time consuming and it takes a lot of effort and I think that cloud computing and software as a service provides that opportunity to distributions.

DP: Yeah. So kind of on that same vein but maybe extrapolating out another few years… do you have a picture of the next big thing in store, Drupal 9, or a fairly long term 3 or 4 year goal with Drupal or just with your own developments or things in general.

DB: Umm… I don’t think… I do, but I’m not sure it’s a picture I can describe.

DP: Okay (laughs) probably a good thing.

DB: Yeah, I don’t know, it’s not like those four features or something. It’s like, for example I believe people’s expectations from web applications are rapidly changing. People expect them to be very easy to use. Very intuitive to use. There’s a lot of very specific applications being developed which are exactly that so I strongly believe that we should make Drupal easy to use

So if I think ahead I see something which is easy to use that’s as good as I can describe it. I also see mobile being much more prominent so I also see something which can be easily accessed from mobile websites or devices.

DP: We were just talking about the good hackability of Drupal and your interest in the cloud and how those things can combined. What you are describing looks to allow for that mobile, more ease of use and multi-device capability that is already upon us.

Lastly, what keeps you motivated. I mean you’re traveling a lot and you’re a fellow father of young ones, what keeps you moving and dreaming.

DB: That’s a really good question. You know for me as long as I can learn I’m having fun. Actually, it’s really having fun. I’m having a lot of fun and the fun comes from being able to learn — from being surrounded by people I can learn from. Just working with the people that I work with, you know all of the people in the community. Working on the projects that I work on, it keeps me really excited. So excitement and fun are it.

DP: Great, well thank you very much for your time.

DB: You’re welcome.

DP: It’s been an absolute pleasure talking to you.

Beyond Spot-Checking: Why LLM Applications Require Specialized Evaluation

  images generated by meta ai Building applications with Large Language Models (LLMs) feels deceptively fast at first. A single engineer can...