[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orion-dev] New Git Repository page

The mutually exclusive thing may be a non-issue. The best example I can think of is PDE editors where different tabs might have very different presentations of the same information. You can edit in either place and they will be synchronized when you switch tabs. This would look odd in a single scrollable document. I might be reaching a bit here because the kinds of things we are looking at using it for (preferences, configuration) don't have that characteristic.

John



Susan Franklin McCourt <susan_franklin@xxxxxxxxxx>
Sent by: orion-dev-bounces@xxxxxxxxxxx

01/16/2012 03:46 PM

Please respond to
Orion developer discussions <orion-dev@xxxxxxxxxxx>

To
Orion developer discussions <orion-dev@xxxxxxxxxxx>
cc
Orion developer discussions <orion-dev@xxxxxxxxxxx>, orion-dev-bounces@xxxxxxxxxxx
Subject
Re: [orion-dev] New Git Repository page





There is also a middle ground between 1 and 2 that I've seen used a lot on the apple site (for example, if you are buying a MacBook and trying to configure it.)
The sections are collapsible, so you can navigate through a massive pile of sections or you can collapse them. For example:

http://store.apple.com/us/configure/MC968LL/A?select=select&product=MC968LL%2FA

Last year, they used an "outline on the left, expandible/collapsible sections on the right" mode. Thought it was an interesting analogy to "Preferences."
But checking the site today, it seems the "outline" is now "section links" on the top, which are less useful, because as soon as you use one of them, the links scroll out of view.

I could imagine adopting (1) all/most of the time and then see where it doesn't work. If there were performance problems generating content that the user might not want, then a pane could stay collapsed by default until the user selected it.

I'm not sure I understand the advantage of mutual exclusiveness that you are talking about. We could decide to put the same information in multiple sections regardless of what UI is used, couldn't we?

Inactive hide details for John Arthorne ---01/16/2012 12:27:15 PM---We have two quite different navigation metaphors here. 1) iJohn Arthorne ---01/16/2012 12:27:15 PM---We have two quite different navigation metaphors here. 1) is an outline metaphor where I have a con

From:
John Arthorne <John_Arthorne@xxxxxxxxxx>
To:
Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date:
01/16/2012 12:27 PM
Subject:
Re: [orion-dev] New Git Repository page
Sent by:
orion-dev-bounces@xxxxxxxxxxx




We have two quite different navigation metaphors here. 1) is an outline metaphor where I have a contiguous large document and the pane helps me jump around. 2) is a tab folder metaphor where I conceptually have a pile of documents and clicking a tab brings that one to the front. I think we need to avoid using the same presentation style for both cases since they are conceptually quite different. We will probably have uses for both of these metaphors but they need to be visually distinct. The presentation given by Anton definitely looks like 2). We wouldn't change the background colour of the selected tab if the user could scroll to another section and cause the tabs and document to no longer match. Having said all that I don't know what I would prefer for the repository page. I think I would opt to keep it as a single page for awhile and see how that feels (as it is now). I kind of agree that splitting it up into multiple pages adds back some of the extra clicks we were trying to get away from with this new layout.


Another random benefit of 2) is it works in cases where the categories are not mutually exclusive. For example if I had information that I wanted to have appear in multiple tabs, or a meta-tab like "Recent" or "Search" that shows content from multiple sections.


John


Susan Franklin McCourt <susan_franklin@xxxxxxxxxx>
Sent by: orion-dev-bounces@xxxxxxxxxxx

01/16/2012 02:58 PM

Please respond to
Orion developer discussions <orion-dev@xxxxxxxxxxx>


To
Orion developer discussions <orion-dev@xxxxxxxxxxx>
cc
Orion developer discussions <orion-dev@xxxxxxxxxxx>, orion-dev-bounces@xxxxxxxxxxx
Subject
Re: [orion-dev] New Git Repository page







My two cents on this specific case:

I favor (2) for the repo page for the same reasons Szymon mentions. Also, I think that someone who favors (2) probably wants the outliner collapsed by default. (I do).

However I could see that in some contexts (pref page?) a variant of (1), or at least the outliner defaulting to being on, would be helpful, for a couple reasons.

- When the sections on the page are very heterogenous (such as preferences) the user task is probably related to the selected state of the outliner. For example, I want to go modify the plugins list. If I last was looking at the "plugins" list on the pref page, then when I go back to the pref page, I probably want the plugin info to show first. (Especially if I navigated away from the page and then used history to get back.)

- for performance. If it's expensive to generate the information about a section that the user might never visit.

For the general case, I like (2) because I think of this as just another "outliner" and of course the editor outliner works this way.

susan


Inactive hide details for Szymon Brandys ---01/16/2012 11:47:56 AM---The sidebar would facilitate navigation on the page and I Szymon Brandys ---01/16/2012 11:47:56 AM---The sidebar would facilitate navigation on the page and I plan to add it. The question is what shou

From:
Szymon Brandys <Szymon.Brandys@xxxxxxxxxx>
To:
Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date:
01/16/2012 11:47 AM
Subject:
Re: [orion-dev] New Git Repository page
Sent by:
orion-dev-bounces@xxxxxxxxxxx




The sidebar would facilitate navigation on the page and I plan to add it.

The question is what should happen with the page content when you click on the sidebar. I can see two options:

1) Clicked section is shown and others are hidden

2) You see all sections all the time and you are just scrolled to the clicked section


Anton seems to vote for 1) and I prefer 2). The new repo page is not a big page really, so there is no need to hide sections and I like to see everything at once. Otherwise I would again have to make extra "click, click" to see what the repo state is.


Moreover the landing repo page does not show everything, but just the most recent data. When you want to see the full list of tags or branches you click on "See all" links.

But when you open repo page showing the full tags list, there are only two sections, so hiding one of them does not make sense to me.


Going to te sidebar itself, I think it should be hidden by default and just open on demand when people want to quickly jump between section.

I wonder what others think...

--
Szymon




From:
Anton McConville <Anton.McConville@xxxxxxxxxx>
To:
orion-dev@xxxxxxxxxxx
Date:
2012-01-16 20:03
Subject:
Re: [orion-dev] New Git Repository page
Sent by:
orion-dev-bounces@xxxxxxxxxxx





Hi Szymon,

I like the approach ... but have a request for consideration of a slight variation on it ... this is just for discussion ... to see what you and others think of it - see the attached screen-shot.

The idea is on a per repository basis, we access the various subcategories of repo data from the sidebar. To me it organizes the data a little bit more cleanly and accessibly. Others might like to see it all on one screen. This seems to me to be a place for your other work item for presenting the configuration data.

Anton

(See attached file: repository.png)


Inactive hide details for Szymon Brandys ---01/16/2012 10:47:25 AM---You can see the new repo page using [yourserver]/git/git-rSzymon Brandys ---01/16/2012 10:47:25 AM---You can see the new repo page using [yourserver]/git/git-repository.html# address.

From:

Szymon Brandys <Szymon.Brandys@xxxxxxxxxx>

To:

Orion developer discussions <orion-dev@xxxxxxxxxxx>

Date:

01/16/2012 10:47 AM

Subject:

[orion-dev] New Git Repository page







You can see the new repo page using [yourserver]/git/git-repository.html# address.

This page is going to be the default repo page and you will be able to open it by clicking "Repositories" link in the header soon.

The old page will be available under [yourserver]/git/git-clones.html# at least till the end of the 0.4 release.


You may start using the new page and feedback is welcome. Let me know if you see any issues either via this list or Bugzilla.
The only missing feature comapring to the old page are repository preferences, but this will be added soon.


Thanks

--
Szymon




From:
John Arthorne <John_Arthorne@xxxxxxxxxx>
To:
orion-dev@xxxxxxxxxxx
Date:
2012-01-14 03:06
Subject:
[orion-dev] orion.eclipse.org workspace wipe completed
Sent by:
orion-dev-bounces@xxxxxxxxxxx




We now have a fresh workspace on orion.eclipse.org. Let me know if you have any difficulties logging in or other account problems. Also if there is any content in the old workspace you now realize you need, just send me a note and I can recover it for you.


John
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/orion-dev

[attachment "repository.png" deleted by Szymon Brandys/Poland/IBM]
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev