Martin Walsh wrote: > michelle olson wrote: > >> Hi Martin, >> >> The changes you've made so far look great, the app is much easier to >> navigate already. My reply to your question inline below. >> >> Martin Walsh wrote: >> >>> Mike Kupfer wrote: >>> >>>> A distinct but related concern about the Repository link: >>>> >>>> I just got around to playing with the testbed, and I thought that the >>>> behavior of the Repository link was odd. If I just click on it, it >>>> complains that I haven't selected a repository. Seems like it should be >>>> grayed out if it isn't going to do anything useful. >>>> >>>> >>> There have been some mention of this. I originally had this so that >>> the repository link only appeared once a repository has been >>> selected. But I reverted to the link always being there, with the >>> consequence of the error message if no repository was selected. I >>> have now updated this, so that the link is disabled if no repository >>> is selected. >>> >>> The other issues you mentioned should now be fixed/updated and are now >>> on repo.opensolaris.org. >>> >>> Any suggestions about the action column on the list of repositories? >>> Remove completely? >>> >>> Michelle, just a follow up. Do you think that the suggestion of >>> another page containing just the repositories is OK. And we also keep >>> the list on the main project page to. >>> >> Yes, I think we need another page containing just the repositories list. >> I also think you could collapse the Participants page into the >> Repository page, as a second section. So, you'd still have three page >> 'levels', but Repository is a container for edit, verify, and >> particpants, as described in the diagram I've posted here: >> http://www.opensolaris.org/os/project/website/content/project_layout.pdf >> > > Just to confirm, are you suggesting that the menu will include the each > repository as a sub-menu of the repositories link? e.g. > > Project > - Leaders > - Operations > - Repositories > - Spec > - Portal > > If so, although this will be fine for the standard project, but some > projects have a lot more repositories. i.e. one project has 22 > repositories. Do you think that would be a problem, as the menu could > get long. > > Note that there is actually no limit on the number of repositories per > project, and that there is currently no way to delete a repository. So > the number of repositories could get pretty large. >
If the app is implemented in the same way as we do it today, there should be room in the left-navigation for a long list of repos. But, I can see how it is a 'triplicate' if we have the repo table on the Project page, the Repositories page and in the navigation, so we should eliminate one at least :) > >> The text on the right describes the content for each grey square >> 'landing page'. >> >> You already have three levels, so I'd suggest that you use the third >> level for repos, rather than participants, to make it more intuitive >> because currently, you can be on a participants page without having any >> indication of the associated repo your searching unless you go back to >> the repo page. >> > > I am not sure about this, as I think that this is probably going to be a > highly used page as it allows participants to become contributors, and > vice versa. There could be large numbers of participants, especially > when the gate moves outside. If the user is updating contributor rights > for several people, when the update is clicked, or the next page of > participants is selected the user will have to scroll down past the > repository details. I think that this could prove annoying, so I think > it requires its own page. e.g. > In this case, the user would have to scroll through the large list of participants anyway, so I think the benefit of having the repo details listed with the participant list that the user is modifying still outweighs the problem of scrolling. > Project > - Leaders > - Operations > - Repositories > - Spec > - Participants > - Portal > > The link for this would be a child link of the repository, giving the > menu system 4 levels. Is this acceptable? > I'd prefer to see all of the actions you can perform on a repo (edit, verify, search, show all, and update) on the same page, keeping the menu to three levels. As an aside, for consistency with the Repository page buttons, you might change the Update button on the Participants page to Save and add a Cancel button. > I could put the name of the repository we are dealing with in the page > header. e.g. Participants - Portal Repository. > The user will have to select the repository they want to deal with, and > they will have the reminder at the top of the page. > It would be an improvement to have the repository name on the Participants page as you suggest, but I still think it would be better to just include the participants section on the repository page. Maybe this won't work well as you jump to the Edit page or Search results page? If so, I think that at least having the addition of the repo name on the Participants page would suffice. Thanks, Michelle > >> If you make these suggested changes, I think you can safely remove the >> Actions column on the repo table, since the link to the repo page in the >> Repository Name column will provide access to all the same actions and >> details. >> >> > _______________________________________________ > website-discuss mailing list > website-discuss at opensolaris.org >
