• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (32)

1 localhost commented Permalink

I'm not sure I totally "get" this, but one thing I know is that little icons (especially if some of them might be similar or the same) are less clear than text. So I think I lean towards option 2 or 3. (But I'm not sure I understand option 4 correctly, sorry.)

2 localhost commented Permalink

I like Option 2. The user can easily see the menu "Sidebar Panels" and from there chose the ones they want.

 
Darryl

3 localhost commented Trackback

Hi, I would go for option 2, maybe renaming "Sidebar Panels" into "Panels", the sidebar is already the logical context the user is working on.

 
I've been working on the Expeditor release for the last week (great platform) and trying to figure out which is the bestway to build apps.
 
Even when you know eclipse it's not trivial to get the best result in the new client. Sidebars are something out of eclipse "perspective based" view and developers need to understand this.
 
I also think using the "mini sidebar view" (icons) to select which panels to show is going to be confusing. What happens when the sidebar is collapsed, what when it's open ?
 
Same thing for the "miniapp" context menu. It should be local to a miniapp so it shouldn't include any "global" commands, some miniapp can even hide their titlebar.
 
The global (per sidebar) panels menu/chooser is the good choice for me.

4 localhost commented Trackback

Option 2. Saves screen space. Then menu in option 3 has panel properties, and its more clicks to change panels.

5 localhost commented Trackback

I like all the options - they provide great enhancements to the current working code (I'm one of the IBM internal beta testers ;-).Maybe you should take a look at the "All-in-one sidebar" extension for firefox (http://firefox.exxile.net/aios/). I use this all the time.

 
coupling the sidebad layout to locations would not apply to my usage patterns at all.

6 localhost commented Permalink

I would prefer option 2, because1. it seems to me that this is the common paradigm for all kinds of toolsbars, so it seems to make sense for sidebar switching as well.2. it's better than option 3, because in 3, the menu depth is too deep. Too much clicks to get the user to what she wants.

7 localhost commented Trackback

I like #2 best. It was the only one that immediately made perfect sense to me.

 
I did have one question, though. The panels are saved in sets called layouts, right? So why are the layouts listed below the panels that can be activated? The picture makes it look like I could change both and that they have nothing to do with one another, when in fact there's a hierarchical relationship between them. It also makes it look like IF there's a relationship, the hierarchy is reversed, because the layouts are on the bottom. Or have I misunderstood what the layouts are?

8 localhost commented Permalink

Option 2 looks fine. One thing I wondered about is whether there is the possibility of changing the layouts programtically, perhaps based upon the app which is open in the main window. I can imagine situations where I would like a certain set of mini-apps to be associated with e.g. my TeamRoom, but a different set to be visible when doing something with the e.g. CRM app.

 
Just a thought

9 localhost commented Trackback

#2. Totally. #2.

 
Its the one that's most intuitive, least intrusive and best looking.

10 localhost commented Trackback

Option 2 is most intuitive. Makes also sense in SameTime client.It would make sense to link sidebar layouts to location documents (for me). However this is not necessary in the hannover release, but can be a nice improvement in a next release.

11 localhost commented Trackback

Option 2 is the best.And my opinion is that saveable "sidebar layouts" are not really necessary. It will be enough that the user can show/hide the panels itself. Keep it simple (this time :-)).

12 localhost commented Permalink

If these are the options, I'm in with everyone else, option 2.

 
Although, in first glance (and even after several glances) just looking at the drop down titles of "Sidebar Panels" and "Layout: Messaging Tool", neither is intuitive to me (guess I'm just dense). If more "plugins" get written the list will become unwieldly, especially with the user defined "Sidebar Layout" configurations the user can create. The name "Sidebar Layout" is confusing because it doesn't have anything to do with the drop down "Layout: Messaging Tool" drop down (does it? - or am I really missing it?).
 
Isn't "Sidebar Layout" really "Sidebar Position" (or Positioning or Location)? Shouldn't the "Sidebar Layout" that the user can create be a two sided box with the right side being the defined layouts, and as the user clicks on the layout, the corresponding "plugins" are checked in the left hand box. This would accomodate a scrolling list for the "plugins" as they become more numerous.
 
Maybe I'm just way off base on this.....
 
/Dale

13 localhost commented Permalink

Correction - Can't tell my right from my left. The paragraph should have read:

 
Isn't "Sidebar Layout" really "Sidebar Position" (or Positioning or Location)? Shouldn't the "Sidebar Layout" that the user can create be a two sided box with the left side being the defined layouts, and as the user clicks on the layout, the corresponding "plugins" are checked in the right hand box. This would accomodate a scrolling list for the "plugins" as they become more numerous.

14 localhost commented Permalink

Personally, I think that option 2 is the best. As to the concept of "sidebar layouts" - Kill it with fire! Some power users may catch on to it, but it's extra UI bloat that Samantha will not understand, and likely never have any interest in using.

 
Remember, we don't want to present all choices, just the right choices - and all within two clicks.

15 localhost commented Permalink

I vote for option 2 too.Saveable layouts do not seem mandatory (at least in release 1, oh sorry, release 8.0)./Pierre

Add a Comment Add a Comment