I'm not a fan of "settings" pages. They give a terrible interaction experience.
To change settings on a settings page, I have to stop what I'm doing; open the settings page; find, change, and often save the setting; then find my way back to what I was doing. If my change wasn't exactly what I wanted, I have to do it all over again.
More often than not, this breaks my concentration to the point where it may take me minutes to figure out what I had been doing, and get back to it. Productivity tends toward zero.
So, I'm trying something different with BeerRiot. I'm going to try to keep all settings relevant to the page they affect on the page they affect. No need to leave to find the setting elsewhere - just change it and update.
I forsee only a couple of occasions that I'd ever have to make an exception: the structures to change the setting would consume too much space, or the setting doesn't relate to any other page. The latter is already exemplified by email and password settings.
I think these exceptions being on separate pages may make sense, though. If the structures take a lot of space, they may be complicated, so focusing on them alone may be helpful. If they're not related to the page I'm on, then I'm probably not worried about getting back to that page after I change them.
Today I have the default map view setting on the map view page, maximum item list lengths on each item list page, and each member's public information on their own public page. I think they fit pretty well, but of course I'd like to hear what you all think.
Also, does anyone know of any research on this topic? I've read a bit of general user-interface stuff, but I don't recall anything that specifically spoke to "settings" pages.
Categories: Development
Post Copyright © 2007 Bryan Fink