InstantGallery 2 update
Wednesday, June 06, 2007
I really should stop promising software in 'x' amount of time because I'm a bit hopeless with deadlines when it comes to software. Needless to say InstantGallery 2 will be fashionably late. It will however seriously rock your world if you want to make amazing photo gallery based websites. I've put together a quick videocast to demo how I've incorporated lots and lots of new functionality into IG 2 without cluttering the interface or creating a bazillion palettes and dialogs.








10 Comments:
Looks amazing. Thanks for posting the video. However, and if I may say so, I am not 100% certain about the iPod style interface as you quite a bit of screen real-estate on a mac screen (tabs do work well :-) ).
By the way, I work as a usability specialist for a cell-phone company and if you do need Alpha testers I would be honored to be one. My email is adrien(at)pitrat.com.
The problems with using tabs is that they get smaller and smaller the more you add and it gets even more messy when you need to start dealing with tabs that need to change depending on the context in the application. The idea with the iPod style menu (which was inspired watching Apple's iPhone ads) is that it allows an almost unlimited amount of functionality to all be put in one place without creating a horribly cluttered UI. I'll let you know when I've got a beta ready :)
Thanks a lot for having taken the time to reply to my post :-)... I have no doubt whatsoever that the V2 will be as beautifull and usefull as the V1.
The iPod like interface looks really interesting - an extension to the NewsLife way of doing things, which works well for the linear way in which that app is used.
However, as the previous commenter wrote Macs are getting larger and larger screens, so space is not a huge premium. The major disadvantage is that the user is constantly moving backwards and forwards through the interface and can easily get exasperated trying to find things, or having to go to several panes to change behaviors. What is needed are some navigational clues.
One possible solution would be to allow users to have multiple inspectors open so they could view and change multiple settings simultaneously.
Alternatively you might want to look at the Lightroom interface which opens and closes multiple panes simultaneously, but always lets the user move from one module to the next with a single mouse click.
It's true that Mac's have pretty large screens these days, but they're not likely to get much bigger than they are now - pixel densities will go up for sure, but again we're moving towards resolution independence so controls and windows aren't going to be shrinking as those resolutions go up. When you're working on something visual like a webpage you don't want to have to manage palette windows, shuffling things about to see what you're actually working on. The idea behind this inspector is to contain a lot of functionality in one place. I'm continually frustrated by having to move palettes around in apps like LineForm and Photoshop because they're obscuring bits of the documents I'm working on and I want to try a new way. The inspector is context sensitive which will become apparent when I demo the app more, the amount of manual navigation in the menu will be reduced by this - e.g. you select an image in the source list to edit it and the inspector will show the image settings submenu. Most of the time you'll only be one click away from changing the settings you want.
Might I suggest that you add a crumb trail (possibly in the title bar), similar to the way that Column View works in the Finder, so that you can easily see which panel you are currently looking at.
I think it's very cool that you've been able to accomplish that, but I have to say that I don't like it.
Because the height of the thing keeps changing, the whole control seems way too schizophrenic to me. In addition, all those clicks add up, and I'd get frustrated very quickly that I have to keep clicking just to get to a certain preference.
The reason that works on the iPod is that it's only your thumb involved. With that control on a Mac, you're now involving a whole arm if the user has a mouse, or a finger and a thumb if they have a touch pad. Way too much effort on the user's part if you ask me.
Also, keep in mind that that particular menu interface is probably patented by Apple (remember the Creative suit?), so they may not like you using it...
Anon: the height of a window changing in an inspector is nothing new - look at the one in Keynote or Pages. There really aren't any more clicks, just before you'd be deciphering tiny icons and clicking tabs.
Creative's patent refers to the use of a menu for navigating music in a specific kind of way, being able to drill down through Artists > Album > Song. They don't have a patent on hierarchical menus!
This is functionally equivalent to apps which put settings in a tree ( eclipse, lots of classic mac apps ). It is a nice graphical effect, but it has the same problems as the tree layout, and more. The biggest problem with tree layouts of settings is discoverability, and memorability. Too many options, disconnected from the data. They are hard to remember and hard to manipulate.
This layout adds another problem, in that you cant tell where in the tree you are, because there is no context. Adding a breadcrumb would help. Additionally, if a user wants to twiddle settings on two different panels they have to jump through a lot of navigation to do it. At least in a tree you can drill down to both panels and have one click access to them.
Ultimately, I believe that when you see a lot of options in inscpectors it is a symptom that the user cannot perform enough direct manipulation of their data.
This is still early UI, there is already more context information shown in the current build. Also a lot of the context comes from the rest of the user interface too which you can't see in this video - i.e. you have an image selected in the source list in the main app window and the inspector shows you the list of image settings submenu. It's not intended to be used as a standalone interface. I maintain that a two level deep tree is no harder to use than an inspector with a row of 10 16x16 pixel icons who have panes subdivided by sets of tabs which is what the current standard is.
It's just not practical to allow direct manipulation in a lot of cases, it's not like we're dealing with textual data in a table here, we're talking about images and layouts and all kinds of complex visual things that can't reasonably all be represented there at the same time.
Post a Comment
<< Home