Wednesday, 25 May 2011

Re-design a fascinating opinion

Lou Rosenfeld presented a fascinating talk at the London UX 2011 conference titled Redesign Must Die.  Obviously this is quite a contentious heading for a talk presented to people who make their living from redesign.  He primarily presented the University of Michigan's website and its extremely regular redesign strategy.  Essentially asserting that the redesigns seemed limitless and a waste of money...

Now one element that has always generally irked me when design projects for customers is that I have always felt they do not understand the potential for the software.  Actually more precisely it is not the customer's narrow vision, but more the sales/management idea that this should be so rigidly adhered to.  Essentially the customer will ask for exactly what they have already only incrementally improved, the famous quote attributed to Ford sums it up "If I had asked the consumers they would have told me they wanted faster horse...".  So when Lou talks of avoiding redesign it certainly reminds me of this incremental improvement approach.

This is not to say that an incremental approach does not have some great benefits.

look it's version 2.0, runs 30% faster and is a bit shiner...

The good thing about incremental enhancement as opposed to more radical redesign strategies is that it is almost impossible to anger your existing customers.  Simply improving performance, tweaking readability and minor graphic refreshes are unlikely to get anyone worked up and make the customer feel they are getting a better product. Also minor changes are unlikely to lead to bugs, unexpected usabilty issues, deadlines are easier to keep, the list is long enough to make it appealing.

The problem with this is if you work in such a fashion a new competitor can seemingly overnight produce a dramatically superior product.  If your current design cannot cope with this new paradigm then the catch up phase can be significant, especially if your technological base has stagnated.  This new paradigm might require features your older platform simply cannot cope with, attempting to re-work your current designs could be very costly and a redesign to anticipate this type of problem could have saved the product.

I believe the relatively well known recent history of Nokia and Apple demonstrates this issue, I perhaps could also point to Facebook and Friendster, but lets focus on Nokia and Apple initially.  While Nokia were incrementally improving their phones adding a few megapixels here and there Apple came a long with a relatively new concept which was so superior that the switch to iPhones has been massive.  Nokia's UI had so many significant problems that the new Apple UX was impossible to compete with.

Collectively I suspect that these systemic problems could have been dealt with inside Nokia in a collaborative fashion, but reports of lack of coordination between the hardware and software teams, and the range of markets they were aiming at and a lack of willingness to abandon their current software and either move to an alternative or redevelop their own lead to their endeavor collectively failing.

Nokia's sales and marketing teams drove the incremental changes, because that is what they thought the customers wanted, that's what the surveys said, but sales showed what they really wanted was an iPhone.

Now if you are following this argument then you may be thinking, but hang on the iPhone exhibits the same behavior, iPhone 3G, 3GS, 4, they are all incremental improvements.  This is where the "Redesign Must Die!" aspect kicks in, if your interface is fundamentally correct then you should not redesign it.  Imagine Google moving its search box top right, bottom left, top left every month, fundamentally placing the search box front and center is what people want and expect.  If each version of a product you have to relearn the layout and functionality then it is frustrating and you will not continue to use it when a replacement is available.

But the same argument is apparent in that if the UX is fundamentally flawed then you really need to redesign as early as possible to assist users in "un-learning" the incorrect behaviors.

If you are a real master like Apple you can even use your advertising to teach users about the new features and how to use them, so that when changes do come a long users are not only are they anticipated the learning curve is removed allowing the user to appreciate the benefits of the redesign rather than complain asking for the old design just faster and shiner.  As far as I am concerned these training adverts are a marketing master stroke, and while they may not be the first to do these, they do manage it much more elegantly than most.

Perhaps for clarity I should add that there have been some significant changes in iOS which shows Apple's willingness to redesign.  Although the OS looks relatively unchanged over the years, the modifications to allow elements of multi-tasking were vital to the company realistically competing with Android.

Additionally I feel the the Redesign must die talk was about aiming to correct systemic problems and avoiding change for the sake of change.  Having worked in software for a few years now I know that this is very tempting.  Customers will not easily notice under-the-hood changes, they may not be certain to spot efficiency improvements, but alter the icons and the application will definitely feel new.  Fiddling with the layout sometimes is necessary to convince a customer there are genuine improvements, to allow the customer to reinspect the application with new eyes and not assume all the same issues are in this new software.

Redesign is at its best when it is addressing problems with the current design, no application is perfect, there is always scope for improvement, whether incremental improvement or complete redesign is warranted should be something the designer can access, but it is unlikely that a sales department or "average" customer will be able to initiate such a process.

Wednesday, 11 May 2011

Woohoo there is a way of turning off my most hated Windows 7 feature

I really dislike the Windows Shake.  I have not yet been in a situation where I want to minimise all windows except for the one with primary focus.  I cannot think of a generally realistic situation where I would want to.  With the Windows Key shortcuts, the taskbar preview and the search feature this feature is certainly redundant for me.

However I can accidentally trigger it when comparing information from 3 windows and do so perhaps once every 2 weeks, hence my joy in finding out how to turn it off.

Does involve not just modifying the registry, but actually creating reg keys, something that is fairly uncommon unless you are manipulating your own software, but hey never knock a solution to your problems.

Samsung Galaxy S vs iPhone 4 - finally no contest...

Well my wife has an iPhone 4 and I have a Samsung Galaxy S.  I am not one of those petty fanboys so I feel I can comment in a relatively unbiased fashion about the differences between the two.

Up until recently I felt it was a relatively even contest.  I loved that I could run flash on websites, and that I could run multiple tasks simultaneously, my phone was lighter and thinner than any case enclosed iPhone.  However, I did envy the iPhone's text rendering, as well as the mute switch on the side.

There was one feature I thought I would be upset to not have and that was the camera flash.  The lack of a camera flash has not been that big an issue for me, especially as the iPhone's flash really does give everything a horrible yellow hue, which requires post photo filters before the picture is actually usable, in most situations the cameras are equal.

However, Samsung recently released Android 2.3.3 on the Galaxy S and this update is amazing.  The biggest new feature is the unbelievable battery life.  As I type my phone is on 58% battery, how long did it take to reach this level, 48 hours!  Prior to the update I would need to charge my phone every night with the phone reaching ~10% battery after a full days use,  but right now it is potentially up for 4+ days, something not managed since my old Sony phone from 6 years ago.

Essentially I cannot see why now someone would choose the the iPhone over the Galaxy S, not only is the Galaxy S generally better, but you do not have to fight iTunes to get something on to the device!  Of course the Galaxy S II is out now and the iPhone 5 is no where in sight, if there was genuine perfect information in the market Apple would be looking at a serious loss of sales to Samsung.  Fortunately for them this is not the case and the iPhone will continue to out sell superior devices...

Friday, 6 May 2011


In a previous post I suggested that at a certain size hierarchies serve little purpose, actually this is not strictly speaking true.  Hierarchies of data have two effects they both simultaneously obscure and reveal useful data.

They can help lead to serendipitous discovery through browsing, however, by an item appearing in one sub-menu and not another it can lead to useful data not being discovered if the archiver's mindset is different to that of the seeker.

Librarian's have worked on classification systems since their inception and be it Dewey, Library of Congress or any of the more specialist scheme they all have their issues.  Someone researching a specific individual who has written poems, scientific literature and novels could have their work in very different locations in a Library or could all be grouped together depending on the scheme used.

As you can see the archiver's choice of hierarchy directly effects the efficiency that the data can be retrieved and the potential for serendipity.

Now while hierarchies of data can theoretically have plus points I feel that any time spent on the creation of hierarchies would be much better spent on creating superior meta data and enhancement to the search engine that is used to harvest from this data and cross information links between appropriately linked articles.

By enhancing metadata and improving search engines then my previous example proves this important point.  A person researching the example author would instantly gain access to all their works and be made aware if they were not already that the author had a diverse catalogue of items.  Anyone who was looking at poetry would be made aware that the author worked on other areas and may be curious to investigate them and how they may have influenced the work that they are investigating.  A set hierarchy makes the only one of these outcomes possible, a good search and meta data leads both outcomes to become realistic.

Disaster averted

My lovely Sony DSC-F828 camera stopped charging the battery and started displaying an error message "For InfoLITHIUM battery only".  The manually helpfully told me that my InfoLITHIUM Sony branded battery was not an InfoLITHIUM battery.

I obviously feared the worst that possibly my camera was possibly failing to detect the battery type and preventing me from using the camera.  I checked all of the contact points and performed a camera reset, but still my battery failed to function...

Purchased a new battery and luckily have discovered that it was just the battery that had become faulty.  Woohoo no need to get a new camera. Ok there was some disappointment in this despite my complete lack of funds to purchase any replacement :).

Thursday, 5 May 2011

Did Moodle not get the memo?

I cannot tell you how many programming books I have read which drill in the importance of documentation.  Of course documentation is not always perfect, but I genuinely thought that every programmer realised it was vital to the health of a project that the documentation is as good as possible.

Reading this sentence though suggests the Moodle development team have been reading a different set of books to me:-
Normally, if you want a particular sort of setting, the easiest way is to look around the admin screens of your Moodle site, and find a setting like the one you want. Then go and copy the code and edit it. Therefore, we do not include a complete list of setting types here.
It is perhaps stranger still to me that the most important set of documentation the How to create a Moodle Block is still not up to date with the current version!  Luckily is you spend enough time looking around in the PHP code you can find the information you want, but this should not be the preferred method as the above code suggests.

Copying code without understanding is simply bad, you will introduce bugs and inefficiency copying over redundant or incorrect code accidentally re-use variables etc and break an application in an unexpected manner.  Copying code and referring back to the documentation about the code is much better as it allows you to appreciate what the code is doing in its entirety and perhaps identify bugs and inefficiencies from first principles.

Now as a developer I understand the need to work on the next feature or fix a bug is great, but Open Source only works as a model because of 3rd party contribution, without good documentation 3rd part contribution is significantly harder and open source's main advantage is massively eroded.  Going through the source is a great benefit, but should never be the first port of call for a 3rd party developer.

Web Searching

Search technology is a great interest of mine, fast accurate searches make a massive different to any information retrieval task.  How much relevance ranking, search faceting, related terms have made a massive different.

It certainly appears to me that no matter how well designed a nativation hierarchy is, after a certain number a search engine is dramatically superior. 

I am unsure if there has been any research into maximum acceptable items contained within a navgation hierarchies is useful, but they quickly become unusable to anyone other than the original archiver when they span more than 3 tiers and although the number of items within each tier could vary I would suggest that anything larger than 1930 items would be extremely difficult to navigate without a search tool.  This is assuming a 3 tier hierarchy with 8 items in the first and second tiers and 30 in the final tier.

After reading an article on designing a mobile autosuggest it did remind me of one of the poorest design decisions website manufacturers can make, getting rid of the search box!

There are so many poor mobile design patterns on the web today (just see ITV's mobile website!) but removing the search box is the worst.  Please if you are designing a mobile website make sure that it is still usable on a good smart phone, not just some early colourless nokia with a screen 64*64 pixels wide!

Things you should NOT do on a mobile site:
  • Remove the search box
  • Use different HTML between "mobile" and "desktop" sites
  • Prevent access to the desktop version
Following those three simple rules avoids most of the biggest frustrations a mobile user can have.  I genuinely hate it when I have searched Google found the exact article I want to view only to visit the site and be redirected to the main mobile page... This can often be made even worse when the mobile site does not have a search box to allow quickly finding the appropriate article, and can even be compounded when there is no "mobile" version of that page available because the mobile and desktop sites are not in sync.

Additionally there appears to be the assumption that mobile ALWAYS means low bandwidth.  While this is a fair default assumption to work to it should be recognised that mobile devices can be running on a wifi connection that is as fast as most desktops.  Ebay is a prime example of this poor behaviour.  If I am looking for an item and attempting to determine if the item is appropriate I will look at the picture the seller has uploaded.  Ebay provide a low resolution version of the uploaded image, I click on this image and still have a low resolution image which is certainly not good enough to make a decision on, there is no option on this page to get a larger size, something more appropriate to render on my 4" screen.

Progressive CSS, a desktop view link, combined withnot removing major elements is easy, infact I am sure in almost all instances it is easier than the poor two-site solutions that are dreamed up.