Posts Tagged ‘user interface’

What webOS did better…

Having recently upgraded from a Palm Pixi to a iPhone 4S, leaving behind webOS for iOS, it’s easy to find many things that are vastly superior on iOS; not surprising, given the superior hardware on the iPhone and the relative maturity of iOS as a platform. However, I find myself missing a few things I’ve become accustomed to with webOS; things I think webOS simply did a better job at.

While both platform alert you to events, webOS also kept notifications stacked on the bottom of the display until you chose to swipe them away.


Integrated Contacts
webOS automatically imported and linked contacts from multiple sources (Facebook, Gmail, etc.) making it fairly simple to manage (or more accurately, not have to manage) an address book.

integrated contacts

While iOS supports multitasking on a technical level, on a UI/UX level the focus is very much centered on one app at a time, as swapping between apps always requires a trip back to the home screen. The webOS process of sliding between cards was not only a slightly faster method to swap between apps but also fairly convenient when it came to glancing at something in another app and then getting back to what you were doing; the scenario that pops into my mind is texting something from a webpage but not remembering it exactly or entirely, and having to swap between the messaging app and the browser.

Also, swiping a card up and off the screen was a fairly elegant way to close it. Exiting apps is perhaps not a big of a deal on an iPhone due to the larger memory pool, but when you do near the memory limit, I’m not sure double tapping the home button, pressing and holding the app icon, and hitting the remove icon is the easiest nor most intuitive action.


SmallChange and LargeChange properties of scrollbars

These properties apply to scrollbar controls in WinForms, but the concepts are pretty universal:

  • SmallChange is the change in value that occurs when you click on a scrollbar’s arrows
  • LargeChange is the change in value that occurs when you click on a scrollbar’s track
  • I had some vague ideas on how to set these values, but this MSDN entry confirmed by suspicions that the values should be set relative to size of the container and not the size of the content.

    User interface guidelines suggest that the SmallChange and LargeChange properties are set relative to the size of the view that the user sees, not to the total size including the unseen part. For example, if you have a picture box with scroll bars displaying a large image, the SmallChange and LargeChange properties should be set relative to the size of the picture box, not to the size of the image.

Making better progress bars

An interesting study I came across a while back, regarding changing the animation of progress bars to alter users’ perception of how long an activity (e.g. a file download) takes to complete. By just changing the animation of the progress bar, an activity can seem 10% faster to users.

… Harrison’s group generated a series of animated progress bars: some pulsated between pale and dark blue at varying speeds, and others had pale blue ripples moving either left or right, also at different rates, as the bar crept forward (see video).

Many participants said that progress bars which pulsated increasingly quickly made the download time seem shorter than those that pulsated increasingly slowly.

A significant number also said downloads were faster when ripples in the progress bars moved to the left rather than to the right.

Note the key phrase, increasingly quickly; the pulsating of the progress bar has to accelerate.

In terms of the ripples, it seems they need to accelerate (I’m assuming, the article wasn’t specific on this point) or decelerate as well. Constant velocity ripples (such as those in OS X progress bars) actually result in a negative effect:

Apple uses left-moving ripples that travel at a constant velocity for progress bars in Mac OS X. However, many of the volunteers in Harrison’s study said that this type of animation appeared slower than one in which the left-moving ripples slowed down as the download neared completion.

Icons and labels

I was reading Ars Technica’s first look at Windows 7’s UI and one thing in particular stood out for me, the fact that text descriptions for buttons on the taskbar will be going away.

windows 7 taskbar

Text descriptions on the buttons are gone, in favor of big icons.

There are still text descriptions, but they appear over thumbnails that show up when you mouse over one of the taskbar icons.

windows 7 taskbar thumbnails

There’s a big dependence on iconography here. There was a very small bit of this in Vista, as the Start button was replaced with the Windows logo, but these changes are a much greater shift towards favoring icons over icons+text in the UI. Unfortunately, a potential issue I see here is that unless a user recognizes an application’s icon instantly, they’re now forced to mouse over all the taskbar icons unknown to them in order to find the app or window they’re looking for. This may, however, be a non-issue as the taskbar may typically just be filled with application icons familiar to the user, so cases of scanning over unknown icons in the taskbar will be rare. Whether this is a success or not remains to be seen, but the reason this caught my attention was because of something I read a long time ago on the importance of labels, written by a program manager on the MS Office User Experience team,

One of the problems noticed again and again among non-expert users was that people didn’t use the toolbar at all! … people used the menus to reply, forward, and to create new messages.

… one change caused a total turnaround: labeling the important toolbar buttons. Almost immediately, the toolbars were a big hit and everyone at all skill levels starting using them.

It’s not that icons can’t work by themselves, but that most people have a fairly limited vocabulary. Floppy disk = save. Printer = print. …

… considering that I already know how to speak English; it’s a lot of work to learn how to speak “Iconese” on top of that.

What’s particularly interesting is that the icons being talked about aren’t particularly exotic (reply, forward, send, etc. in Outlook), and toolbar icons are perhaps as common as taskbar icons.

Finally, developers will understand this, what happens if you have 2 applications with the same icon? I don’t expect this to be a major concern, but still, I have a bunch of apps I’ve written with just the default application icon, these changes to the taskbar will certainly make switching between them more difficult.

Why Google won

I firmly believe that Google rose and dominated the search engine market not necessarily because it provided better search results, but because it was the search engine that provided the simplest, cleanest, and most accessible user interface. I bring this up because I caught this image on reddit (my new addiction) the other day. Here’s a cropped piece of the image,

google vs. yahoo

Oddly enough, while many search engines have now adopted a Google-esque simplicity to their interfaces (Live Search, AltaVista,, etc.), Yahoo seems to have taken the opposite approach, saturating their homepage with more content – news, top searches, weather, links to other Yahoo services, and a sickening amount of ads. I highly doubt this “everything and the kitchen sink” strategy will put Yahoo back on top.

Programs and Files

This post is about an idea, a simple idea:

End-users of a PC should be able to transfer their programs between computers and easily as they transfer their documents.

There is of course the issue of OS and hardware dependency for applications, but even from one x86, 32-bit, Windows machine to another, transferring a program is a non-trivial process. Yet, from a technical point of view, there seems to be little justification for things to be this way.

So what is a program really and why is it so difficult to move them around?
(Note: This is primarily dealing with Windows and I’ll be referring to Windows 2000/XP/Vista constructs, however, the situation isn’t any better on OS X or Linux)

Part 1: Back to Basics
A program is just data. Some of it is logic (executable files, stuff executed on the CPU) and some of it is just raw information (images, music, settings, user information, etc.). All of this data, at some level, is contained in files.

Files are great because users understand files, they understand the concept itself (a file is an atomic unit of data) and execution of the concept on almost any operating system is such that working with and manipulating files (moving, copying, etc.) is trivial for all but the most illiterate computer users. This is likely why all user documents are single files. This ease-of-use, I believe, surfaces due to the atomicity of a file; everything about a file is within the file itself, and the metadata for a file (file size, time stamp, etc.) is managed and/or computed dynamically by the file system.

When dealing with multiple files that share a common function or purpose, aggregating files becomes necessary and as such we get to the concepts of directories and tags. While there are ways to make either work for what I’m going to describe, I’ll stick to directories as it’s a more familiar concept in the realm of the desktop.

Like files, users understand directories because of their simplicity in concept and execution, and as with files users are familiar with manipulating them. This simplicity comes about due to the fact that, like files, directories can be seen as atomic units of data. While looking inside a directory and seeing a mishmash of files makes it seem very much non-atomic, it is also a homogeneous container (it stores only files) and therefore, it can be viewed as a single object, a container, and this container can, for the most part, be manipulated as a single object, much like an individual file can. While their atomicity is important for ease-of-use by an end-user, directories are also important because they relate to the coupling of files. As mentioned, files within a directory share a common function or purpose, this is undoubtedly true for programs; each directory for a program contains files which are essential to its function (e.g. all of the files in my \Program Files\XML Notepad 2007\ directory relate to the functionality of XML Notepad). This coupling is important because it allows for easy organization, maintenance, and access to the program and it’s program-specific data.

Now to the crux of the matter, if programs are just files, and files are coupled together in directories, it should follow that we can move programs around by just copying directories. Unfortunately this is not the case because the coupling between a program’s logic and some specific pieces of information belonging to it are not coupled together in the same directory. While Windows users may assume that each subdirectory in \Program Files contains all the files for a program, this is not (in general) true, the files in these subdirectories represent only part of their program. The additional pieces of information are contained in the the system registry and/or somewhere within the Documents and Settings folder. This lack of coupling is the reason transference of programs between PCs is difficult and to tackle the problem tighter coupling must be provided while maintaining the operating system features provided by the registry and the Documents and Settings directory.

Part 2: The Registry
First off, the system registry is a nightmare. I can’t imagine who conceived of the idea that storing application level data and critical system specific data in the same location and allowing free access to it all would be a good thing. So much of our current malware, adware, spyware, etc. headaches have been caused by programs doing bad things to the registry. Additionally, although you can technically backup the registry easily, I’ve encountered errors restoring it which makes the backup useless and the only recourse is to reinstall applications just so they can rewrite their registry information. It should also be noted that most typical users I’ve encountered don’t know what the registry is or have a backup of it, but the more important question is, why should they? It’s a construct that simply appeases the operating system, it’s functional benefits could easily be refactored in more user friendly ways.

So, relative to a program, what’s actually in the registry?

  • Program-specific settings.
  • System-wide settings related to a program (e.g. file associations, uninstallation information, stuff that shows up in the OS shell).
The registry is deprecated for the first issue (so I’ve read, but I can’t actually find a Microsoft link), it is no longer recommended that program settings be stored in the registry. For the second issue, it seems that with the CPU and memory of a modern PC, dynamically reading and applying such settings would be a much more ideal solution. This can be done by specifying a convention for the settings file (it can be XML or whatever), then dynamically scanning each folder in the \Program Files directory for these files and applying the settings specified.

There are, of course, technical benefits (application not messing around in the registry) and tradeoffs (performance cost of scanning program directories) to doing this, but from the end-user’s perspective the ultimate benefit comes from the tighter coupling of a program’s files (program settings that effect the OS are no longer part of the registry file, they now reside in their own file, which is tightly coupled together with other program files in the same directory).

Part 3: Documents and Settings
Tackling the registry is somewhat easy as you don’t have to look far to see the flaws of the registry. The Documents and Settings folder seems a bit trickier, but it’s not. The Documents and Settings folder is a manifestation of the needs of a multiuser operating system. Fundamentally, it stores user-specific settings and program-specific setting for a specific user or all users (the other stuff like My Documents, or the desktop, can be moved; well, to a certain extent, some programs still seem to use an absolute path to C:\Documents and Settings\<user>\My Documents instead of querying the OS for the path). User-specific settings are the domain of the operating system so it can whatever it will with these files. Program settings are different, they’re the domain of the program which owns them (that’s a contract between the user and the program, not the user and the operating system). The policy of having the OS handle delineation and storage of per-user program settings seems to be just that, a policy. There’s no reason applications can’t do it themselves. There are 2 possible solutions I see here:

  • Solution A: The program can be written from a multiuser perspective. Querying all users, creating a directory for every user (within the program’s main directory), setting appropriate permissions for the directories created, and storing user-specific data in these directories.
  • Solution B: Create one \Program Files directorie s for every user. In effect, every user can have a different set of programs installed and/or copies of the same programs. Programs store whatever user-specific settings they want (which will be for the currently logged in user) in their main directory.
Solution A is a pain in the ass for developers. No developer is going to want to have the additional burden on managing data for multiple users when it can be done transparently by the OS. Solution A is also not ideal in how it addresses the overall problem, as to move or copy programs users have to either log in as an admin and copy over all the user data folders or figure out their specific user data folder and only copy over that one.

Solution B is ideal in my opinion, even though it wastes hard drive space, but space is cheap and aside from games most programs don’t use a whole lot. With at one \Program Files directory for every user, applications will still maintain transparency in how they manage user data for multiple users and user data can be stored in the application’s main directory. This solution also provides for greater security and stability as users’ program files are independent and they don’t have to risk running something modified by another user. (i.e. every user is in their own sandbox both for programs as well as documents).

The ultimate benefit here is that copying a program becomes just a matter of copying the program’s main directory.

(For sensitive information, the program is then responsible for determining what user information to keep and what to erase after a copy, but that’s as it should be, that information is a contract between the user and the program, not the user and the operating system).

Part 4: Wishful Thinking
I wrote specifically about Windows, but the central idea here is coupling of data, which can be applied across operating systems. The tighter the coupling, the easier it is for the user to manipulate their data as a whole. There’s no reason the same agility afforded to a user’s documents can’t be given to their programs as well.

Also, although I mentioned one directory for all programs, I see no reason why the system I described couldn’t scale to multiple program files directories (for multiple drives or whatever else).

There is, of course, one issue I didn’t tackle, which is DRM. I spoke about copying and moving without mentioning licenses or copy protection, techniques which greatly benefit from the way things are. However, I think that’s a separate issue, and, simply put, I see something terribly wrong with licensing software to a CPU instead of a user.

Anyways, it’s just an idea. In the end, all of this is wishful thinking, and there’s so much inertia and missteps from the operating system vendors that I’m not holding my breath for any fundamental changes. However, there’s something really sad about the fact that it’s easier to install an application on Facebook than it is to install an application on my desktop.