Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 359567 - Hide the Orion banner
Summary: Hide the Orion banner
Status: RESOLVED FIXED
Alias: None
Product: Orion
Classification: ECD
Component: Client (show other bugs)
Version: 0.3   Edit
Hardware: PC All
: P3 minor (vote)
Target Milestone: 0.4 M1   Edit
Assignee: Susan McCourt CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-30 10:08 EDT by Mark Macdonald CLA
Modified: 2011-11-29 12:53 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Macdonald CLA 2011-09-30 10:08:45 EDT
When using Orion on a small-screen device, I really start to notice how much vertical space is taken up by the Orion banner.

In keeping with "giving the pixels to the content", I'd like to hide the Orion banner so I have more room for the editor/compare view/etc.
Comment 1 Susan McCourt CLA 2011-09-30 11:05:26 EDT
are you thinking a way to dismiss it (and remember that it should stay closed?)  A longer term solution is custom layouts (CSS3 media queries) where we could style the page for different devices.  But I assume you mean do something now/soon...
Comment 2 Felipe Heidrich CLA 2011-09-30 11:26:46 EDT
I'd like to close the bottom banner too if I could. The one that starts with "this is a build of Orion..."
Comment 3 Mark Macdonald CLA 2011-09-30 11:43:33 EDT
> are you thinking a way to dismiss it (and remember that it should stay closed?)
Yes: for now, being able to collapse it like the outline view would be enough.

> I'd like to close the bottom banner too if I could.
+1
Comment 4 John Arthorne CLA 2011-10-04 09:21:56 EDT
Collapsing the header would lose the breadcrumb though. Since trees are really useless on a small device I found myself using the breadcrumb all the time to move around. Also there is no equivalent to the (Navigator | Sites | Plugins | Repositories) links across the top if the banner is closed. Wouldn't you just zoom the screen slightly when you want to focus on the content?
Comment 5 Mark Macdonald CLA 2011-10-04 10:19:51 EDT
(In reply to comment #4)
> Collapsing the header would lose the breadcrumb though. Since trees are really
> useless on a small device I found myself using the breadcrumb all the time to
> move around. Also there is no equivalent to the (Navigator | Sites | Plugins |
> Repositories) links across the top if the banner is closed.

I don't rely on either of those very often, so I wouldn't mind seeing them hidden inside a "nav" icon or similar when space is limited. (My current workflow is to open all the files I need to edit in separate tabs and leave them open. In those tabs I'd like to see as much code as possible. I have a separate tab I use for bouncing between Plugins/Repositories/Sites.)

> Wouldn't you just zoom the screen slightly when you want to focus on the content?

In my case I was using a small notebook, not a tablet, so my browser's zoom feature doesn't pan the banner out of view, it just makes everything appear larger...
Comment 6 John Arthorne CLA 2011-10-04 12:36:39 EDT
So you wouldn't want a global setting that applies to all tabs, but just be able to close the header/footer on any given page...
Comment 7 Susan McCourt CLA 2011-10-04 12:48:40 EDT
I opened bug 359875 as a more future looking bug to capture ideas for alternate layouts on small devices.  I thought the point about the breadcrumbs is a good one...on a small device we may want to separate the breadcrumb from the banner (ie, an alternate banner which is only a breadcrumb), or even the breadcrumb appearing in some other navigation menu.

Then this bug can focus on the "what can we do right now" to make things manageable on different devices, such as collapsing the header and footer

(In reply to comment #6)
> So you wouldn't want a global setting that applies to all tabs, but just be
> able to close the header/footer on any given page...

And in this case storing the preference in a non-user scope makes sense because the user would have a different preference when working on a different device.
Comment 8 Susan McCourt CLA 2011-11-23 23:00:34 EST
i'll try something quick and dirty for M1, probably just a keybinding.  We can worry about a general affordance when we look at visual design/layout in M2.
Comment 9 Susan McCourt CLA 2011-11-28 15:21:40 EST
(In reply to comment #8)
> i'll try something quick and dirty for M1, probably just a keybinding.  We can
> worry about a general affordance when we look at visual design/layout in M2.

Did the quick and dirty binding, ctrl+shift+m will toggle the banner/footer.  Made a note in bug 349634 about having an affordance and possibly an alternate layout that includes some elements (breadcrumb).

There is also the issue of whether we should cache state (but then you have to think about how to get the elements back when you've toggled everything off).  So for now the state is not captured and reload will get everything back.  I'm sure people will want smarter behavior but that will require some visuals.

(ctrl+O uses a cookie to remember outline state but you always have the split affordance for getting it back.)
Comment 10 Mark Macdonald CLA 2011-11-29 12:53:33 EST
This is great :)