December 10, 2003 — 17:40

Central Application Switching Usability

In Central - A Usability Problem, Theodore Patrick berates Central's default “single application at a time” launching scheme.

In Central the primary navigation sits atop every application instance. This would be equivalent of an instance of the OSX Dock or Windows Start menu sitting on top of every running application. This only serves to confuse the end user as if they click on another application, the current application is replaced within the same window. Also management of multiple windows is poor in that if an application does not have an instance running, the top application window gets overwritten. This forces applications to be written in a fundamentally different manner in terms of application state. Developers are forced to write applications that constantly maintain state as at any moment another application can overwrite your application instance.

With my developer hat on I'd prefer it if Central didn't work like this too.

Ideally having a Central Menu launch independent application instances would be the best way around the problem. This is especially true if the Central Navigation is removed from every application instance providing less distraction from the end user task at hand. This would allow Central apps to parallel the execution of desktop apps and the end user would not get confused in the process.

There's a compelling case for that, but it could get a bit messy… With my user hat on I'd expect different applications running in different windows to be managed by “normal means” (tab-switching, separate icons in dock / task bar), I'd also probably wonder why Central apps “look different” to the rest of my desktop apps, I wouldn't expect all the Pods to be grouped in a single “Console” window etc.

Comments

  1. From what I understand, one of the outstanding concerns with this initial release will be the balance between how many processor cycles individual tools request, and how many cycles consumer machines will have to give. A pod or agent can still request cycles, but I suspect the overall load in those cases will be less than with an additional full-sized display. Keeping an arbitrarily large number of instances of the Macromedia Flash Player simultaneously running could risk a negative influence on overall performance adoption...?

    (I don't think you'd need to "constantly maintain state"... this would be handled in Application.onDeactivate, yes?)

    If you see (and receive from consumers!) other navigation/UI ideas then this would be great to forward along to the team, as they gear up for another full round of development... there has to be a lot of testing of what actually works for the general public, and with something new like this it's really hard to predict how the range of users will best be served... ongoing guidance is a critical requirement, thanks.

    jd/mm

    Comment by John Dowdell on December 12, 2003 07:15 PM

Add a comment

This Info:
   
Name (required):
Email address (required):
Homepage:
Comments:

Off-topic and uncivil comments may be deleted. The following HTML tags are allowed in your comments: <a> <b> <i>. To make line and paragraph breaks, press return (don't use <br> or <p>).