[sldev] Landmarks and Navigation Update 2008-05-29

[Aimee Walton]

On Jun 6, 2008, at 16:25, Sarah Hutchinson wrote:

> There is a tiny toggle that will be in the top left of the Viewer  
> which will allow you to show and hide the nav bar as you want.

When not in use there should be _nothing_ visible in the main content  
area. I don't want to sound defeatist, but that looks far more like  
unnecessary clutter than simply making the information that's  
_already_ in the menu bar active. Yes, we already have a cluttered  
UI, but adding more clutter doesn't seem like an answer to me, it's  
just side stepping the problem.

Did it get as far as mock-ups of an active menu bar? Maybe overflow  
the navigation into a hideable second line of the menu area (similar  
to what's being proposed for the nav bar) if the window is too small;  
that could be the best of both worlds?

The main world view is what SL is all about, and it needs to be  
protected. For any new fixed UI element to be allowed as a permanent  
intrusion into that, no matter how small, there has to an absolutely  
compelling reason, and I just don't see it when there's a perfectly  
good menu bar.

I know complaining about one tiny little toggle might seem a bit over  
the top, but these things have a habit of setting precedents which  
then allow other things to creep in in the future by eroding the  
boundary.

Living in dreamland for a minute, ideally I'd like to to see the UI  
made up of dockable (and closeable) toolbar sections, so the user can  
decide the arrangement that best fits their window size, workflow,  
interest priority etc. and lose the bits they don't need. Think Adobe  
Photoshop CS3 etc., with saveable workspaces.

Though I know that's way outside the scope of what's being discussed  
here, and there's an awful lot of work that would have to take place  
to make it possible, I'd like to see that as a long term aim for the  
UI. Something to work towards, even in baby steps. To me the Nav  
project should be seized as an opportunity to start the ground work  
for that. Rather than just adding another disjointed mismatched UI  
element, create the generic framework in code using this as a  
prototype, for a more versatile well structured system, for other  
parts of the UI to migrate to in future.

Aimee.