Bugzilla – Full Text Bug Listing
| Summary: | [client] landing page features | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> | ||||||
| Component: | Client | Assignee: | Susan McCourt <susan> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | antonm, ken_walker, mamacdon, simon_kaegi, Szymon.Brandys | ||||||
| Version: | 0.2 | ||||||||
| Target Milestone: | 0.5 M2 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 7 | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 378758 | ||||||||
| Attachments: |
|
||||||||
|
Description
Susan McCourt
I think the feed is potentially still interesting. This way the "New & Noteworthy" document is put in the user's face. If they are using orionhub, they could otherwise be "upgraded" to a new build without being aware of the changes that occurred. I suppose eventually the sections would be "closeable"? In particular the "Getting Started" section is extremely important at first, but after a few days it is not useful. Not really important for 0.2, but just wondering. revisit next release. Note the feed got pulled out by Simon in the requirejs refactoring I'd like to put time into this in 0.4. - greasemonkey scripts (bug 359080) Consider adding up to date information about current builds - gotchas or features now in production. When users get "upgraded" but visiting OrionHub after a refresh, letting them know what's changed and/or what they should be required to do to stabilize their Workspace/Client could be useful. Sadly other work reduced my ability to work on this in 0.4. Deferring to 0.5 I talked to Simon about this. We want to ensure that the usability for a brand new user is vastly improved. So I'll take this bug for M2 and Ken can provide ideas/requirements based on his demo experiences. My initial thought is that we just take the user to the navigator, but if the navigator is empty, we can show some "getting started" tasks for populating it, and then have a way to get back to the "getting started" tasks. At least until we have feeds or other content that is actually interesting for a day to day user. As part of this bug I'd like to revisit some of the ideas in bug 361856 and https://bugs.eclipse.org/bugs/attachment.cgi?id=205865 That bug does introduce some "left pane" functionality when you have multiple file systems but it didn't tackle the creation part of the problem. The creation part, though, is related to the idea of "getting started" when your workspace is empty. (In reply to comment #7) > My initial thought is that we just take the user to the navigator, but if the > navigator is empty, we can show some "getting started" tasks for populating it, > and then have a way to get back to the "getting started" tasks. > > At least until we have feeds or other content that is actually interesting for > a day to day user. Feeds could fit on this page as well. Navigation can be a key part of this page but it really has room (literally pixel-wise and also conceptually) to do much more. marking fixed, as I've released the first cut at this, which is moving the getting started/content creation to the navigator. We can make this prettier, but there are so many pieces involved that I wanted to get all interesting code/info out of index.html/index.js so that Simon could gut it. We didn't really have a bug describing the overall workflow from a "what page is the user on" point of view. Since we currently don't distinguish between branding/landing/login, and since index.html doesn't really do any of those things, I thought it might be helpful to introduce terminology to talk about it. See bug 378758. Also wanted to note: Most of the old getting started content was improved to auto-generate the content so that the user just clicks one button. Sadly, this is not the case for "clone git repository" due to architectural issues (see bug 378755). So right now, the user still has to go to the repo page to clone a git repo. If we want to fix this, we will need to come up with tactical solution in bug 378755. Created attachment 215277 [details]
screenshot of nav on first landing
Here is what a brand new user would currently see after login. I realize this isn't ideal yet, but its a first incremental step. I switched the default splitter to give more space to the LHS. One could argue that this content should appear in the white area, but I didn't want it to disappear completely once content is in. Suggestions welcome.
Created attachment 215278 [details]
screenshot of nav when you have data
For users with data, the "create new content" section still appears on the left, but it will be hidden unless you click "view." A preference will then remember whether you like to keep it open or not.
If you navigate into a project, "Create new content" disappears right now. I originally implemented it by letting the user create new content from anywhere, but it was not very friendly, as you had to be taken back to the workspace root to see what you had created, and that lost a lot of context. In the end, I decided to only show it when you are at a level where you can create a project.
I should point out that the first experience for us (orion.eclipse.org, new build deployed) is neither of these due to bug 368481. The favorites are not found, so you end up seeing "Create new content" up top even though you have favorites. You have to clear local storage in order to get your favorites back. I believe this problem will naturally go away when Simon releases his "settings provider" changes but if not, I will investigate further in bug 368481. |