(FR) Startup-screen needs re-design

[Daniel Kulesz]

After choosing "instant review" on the startup screen (RevAger assistant), the user is offered the option to open an existing Review. But why? If there is already a saved review, this should be rather covered by the "scribe" mode already. Or is there something special about opening previous instant reviews?

Actually I think that both options offered there - the catalog manager and the "open review" function - should be part of the first screen, since they are not really mode-specific. Of course, putting all that those options in the startup screen would make it a bit too cluttered up, since we would have:

- Moderator mode
- Scribe mode
- Instant mode
- Language selection
- Catalog manager
- Open review

Maybe it would be worth considering a re-design of the first screen, i.e. offering only:

- Start new review
- Open existing review
- Open Catalog manager
- Select language

Choosing the first option would allow the user to specify the mode in the following wizard step.

[Johannes Wettinger (jojow)]

Actually it is a really good idea to redesign the first screen. But I think it isn't that simple, because the user e.g. also needs the possibility to open an existing review in Moderator mode, e.g. to plan new meetings for this review and to create new invitation packages.

To improve the usability of the first screen I suggest to redesign it completely. You can find a first prototype attached to this comment (3 slides). If we decide to redesign the screen, we should create a new blueprint for this task.

[Davide Casciato (casciade)]

I think the prototype1 is a good basis for the redesigning, but i don't like the layout concerning the buttons below. In my opinion redesigning is an option.

[Johannes Wettinger (jojow)]

Davide, you're right. The position of the buttons at the bottom is not so good. I've just created two alternative prototypes. The first is 2a, attached to this comment.

[Johannes Wettinger (jojow)]

Here you find the second one, 2b.

[Daniel Kulesz (kuleszdl)]

Thanks for creating this cool prototype Johannes.

Unfortunately I have to (partially) agree with Davide. Although I like the logical grouping in prototype1 very much, something feels counter-intuitive about the buttons' placing and size to me. Also, on slide3 - are there plans to include a "back" button?

[Johannes Wettinger (jojow)]

Concerning the buttons at the top ('New Review', 'Existing Reviews' ...): We can implement them either as tabs (similar to the way we've done it in the protocol window) or as a group of graphical toggle buttons (similar to the toolbar of our new ImageEditor).

The review file selection on the last slide should represent a popup window. You will be able to close this popup window, so there is a possibility to go back to the assistant dialog.

[Davide Casciato (casciade)]

Prototype2a is my favorite, yet. Besides, i don't think that using tabs or toggle buttons would be a better solution.

[Johannes Wettinger (jojow)]

@Davide: ok, but we've to choose definitely one of them. Either we implement it as toggle buttons or as tabs, or is there another possibility? I think to implement them just as standard buttons isn't a good solution because you cannot see the selected "category".

I would prefer normal toggle buttons with a little icon in it (similar to the buttons' style at the bottom of the dialogs), but no "image toggle buttons" like we use them in the ImageEditor.

What do you think?

@Daniel: What do you think about the usability of prototype 2a?

[Davide Casciato (casciade)]

Sorry, i missunderstood you Johannes. Now i know, what you meant. In this case i would prefere the solution with the toggle buttons. Sorry again ;)

[Johannes Wettinger (jojow)]

@Davide: No problem! ;-) I'm going to create a new blueprint for this topic. Do you want to create UI prototypes?

[Daniel Kulesz (kuleszdl)]

Well, I like 2a much more than 2b, since this "Revager" tab/toggle button doesn't make a sensible category. But how about making it more "wizard-style"? Having Icons for the entries "new review" or "existing review" and then having other buttons in the next step (plus a "back" button of course) for choosing i.e. between moderating a review or starting an instant review?

Can you provide a prototype for the "toggle button" solution as well?

[Davide Casciato (casciade)]

For sure. I'll make one for the each of the two solutions ("wizard-style" & "toggle button").

[Davide Casciato (casciade)]

-the ;)

[Johannes Wettinger (jojow)]

Thanks Davide! If you need the source files of my prototypes (OpenOffice Draw), just let me know.

[Daniel Kulesz (kuleszdl)]

Actually offering the OOo Draw files for the prototypes would be very useful in general. Maybe we should establish a common standard for future discussion of UI prototypes, i.e. OOo presenter with embedded OOo draw.

[Johannes Wettinger (jojow)]

I've just uploaded the OOo Draw files for the prototypes.

@Daniel: Your idea regarding a common standard for UI prototype files is great. Could you start a discussion concerning this topic on our mailinglist? Thanks!

[Holger Röder (roederhr)]

Some comments on your comments:

We should strive for consistency, i.e. we should use the similar UI widgets for similar types of actions. For example in prototype2a, I don't think mixing icons-only style (aspects manager) and icons+text style (create new review etc.) for user-selectable actions is a good idea.

Toggle buttons represent binary decisions: on vs. off; I wouldn't use them for navigation techniques. Tabs were made for this.

And finally: Is it really necessary to introduce another navigational layer (new review/existing reviews/...) instead of showing all the options on one screen? The original bug description states the screen would become "cluttered" - In my opinion, however, this is not the case. Having five or six options on one screen should work fine.

[Daniel Kulesz (kuleszdl)]

Thanks a lot for the prototypes. I partially agree with Holger - propably having so many start buttons / options is not a big issue, if we find a good layout for this screen.

Attached is a UI prototype which implements this layout. Of course there are still some design aspects to fix in there. What do you think about this proposal?

[Johannes Wettinger (jojow)]

@Holger: Thanks for your comments! They are really valuable. I've just created a new version of the UI prototype and I think it looks very good! It's my favorite now. ;-)

[Johannes Wettinger (jojow)]

@Daniel: Wow, we posted nearly at the same time! ;-) Therefore I've just renamed my prototype to "prototype4".

[Johannes Wettinger (jojow)]

Daniel, regarding the prototype3: I cannot see a possibility to open an existing review as moderator (e.g. to plan a new meeting for an existing review).

[Daniel Kulesz (kuleszdl)]

Thanks for Prototype4 Johannes. Looks nice, though I like the layout of prototype3 better ;-) This is only concerning the layout.

Regarding your question about opening an existing review: I thought, this should be possible with the "Open" button. Actually I think there is a conceptual problem with this "open" and "start" naming and the concept with the modes. Currently, "scribe mode" means you actually open an existing review, in order to start it.

Maybe we should think about a way to fix this first. Maybe it's even possible to get rid of one of the buttons maybe. Any suggestions?

[Johannes Wettinger (jojow)]

@Daniel: Ok, but then we should rename the "Open" button, so it is clear that's the moderator mode behind it. Otherwise it's a bit confusing for the user.

Another two comments regarding prototype3:
1) As alternative to include a "Back" button, we can use popup windows like in prototype4. ;-) What do you think?
2) I think we should position the "aspects manager" button beside the "select lang." button. That means, either we leave both of them inside the top panel or we move both of them into the main panel.

[Daniel Kulesz (kuleszdl)]

Johannes: Actually, the "open" button would have the moderator AND the scribe mode behind mit. Solving this with a popup like in prototype2b could be a solution, when using a description text like in Prototype3 before.

Concerning the "back" button: There's nothing wrong with the popup windows, but how should we implement the assistant for the instant mode then? (see https://bugs.launchpad.net/revager/+bug/494396 and https://bugs.launchpad.net/revager/+bug/493798)

Positioning lang and aspect buttons: Could look nice to have them besides, new prototypes welcome ;-)

[Davide Casciato (casciade)]

Thank you Johannes for the great Prototype (Prototype4). It's now my favorite, too ;) Daniel, do you like Prototype3 more because of the layout or are there also other reasons? I think Prototype4 would better match the general revager-style.

[Johannes Wettinger (jojow)]

@Daniel: You're right! We should definitely add a 'Back' button because of the instant mode assistant. It's also a good idea to rename the "Close" button into "Finish", so you can exit the assistant in each stage and continue manually in the main frame.

So, I've just created prototype5, an updated version of prototype4. Please feel free to continue posting comments! :-)

[Daniel Kulesz (kuleszdl)]

Thanks for the new prototype...it's getting better and better now :-)

In prototype4 and prototype5 you use rather small icons together with a lot of text, unlike the current 1.2 rc(r19) version. The main difference to prototype3 it has rather few text (just one word below every icon), supported by this explanatory text, which is only visible, when you hover with the mouse over the button. Personally I like this approach better than always displaying the full explanatory text besides every button.

To keep it more consistent, we could employ your already available help system here, to show the explanatory text.

[Holger Röder (roederhr)]

@Daniel: Why hover? Looks nice, but IMHO decreases usability. :-)

@Johannes: I really like p5, though I'm confused of the capitalization. 'Instant Review' (both upper-case) vs. 'single Reviewer' (lower+upper case? I'd also prefer 'Start new instant review' instead of 'Create'.

[Johannes Wettinger (jojow)]

@Holger: That's right! But I think we should capitalize the roles because they are very important in this context. So we can write "Start new instant review as single Reviewer".

@Daniel: Hmmm... our help system is not designed for "updating on hover"; the Taurus team has choosen this approach. ;-) Alternatively we can write only a word beside each icon and when you hover with the mouse over it, replace it by an explanatory text. E.g. we can just write "Instant Review" beside the first icon and when you hover with the mouse over it, replace "Instant Review" with "Start new instant review as single Reviewer" at the same position but with a smaller font size.

What do you think about this approach?

[Daniel Kulesz (kuleszdl)]

Here's an alternative prototype6, which incorportates my suggestions from prototype3 into prototype5. By merging the "open" and "scribe" buttons into one, we could alternativily use a layout with the three buttons in a horizontal alignment. I will post a prototype_6b soon, which demonstrates this.

[Daniel Kulesz (kuleszdl)]

Here comes prototype6b, the same as prototype6 but with a horizontal alignment of the icons.

[Daniel Kulesz (kuleszdl)]

Johannes: I think we're still at the drafting stage. Whether or not we can re-use the internal help system should be a secondary concern. Let's try to find the best solution for this screen first (remember "optimal technology" in LLSE07?). Once we got there, we can still address the implementation details and consider simplifying it.

[Davide Casciato (casciade)]

New favorite: Prototype6b ;)

I think we've almost reached the final solution.

[Johannes Wettinger (jojow)]

@Daniel: It's ok. It wasn't my intention to address the implementation details; should be just a comment to your suggestion regarding the help system. So let's proceed looking for the best solution! :-)

Prototype6b looks nice, but I suggest to move the explanatory text into the top panel: prototype6b1

[Johannes Wettinger (jojow)]

I suggest to mark the following blueprint as obsolete:
https://blueprints.launchpad.net/revager/+spec/spec-choose-language-startup

Reason: The feature will be part of "Startup-screen re-design" which is discussed here.

[Holger Röder (roederhr)]

@Johannes: I have marked it as 'superseded'. Nice feature! ;)

[Daniel Kulesz (kuleszdl)]

I'm not really sure about prototype6b1 - do you think, the user will rather search at the top for the help text instead of looking at the bottom of the screen? Since the buttons are at the bottom, the user might focus more on the bottom of the wizard.

What do the others think about it?

[Johannes Wettinger (jojow)]

To keep the discussion alive, just another prototype: p6b2 :-)

I think it combines p6b and p6b1. What do you think?

[Daniel Kulesz (kuleszdl)]

To be honest, I would prefer 6b and 6b1 oder 6b2. I think the help windows should not "cut apart" the function buttons into two parts. One other variant I also thought about is to put the less important functions (language, aspect manager) in the background by using a Layout like in the gdm "faces-browser" display manager:

http://files.opensuse.org/opensuse/en/a/a6/Os103-gdm-userlist.png

(it has the main functions in the center, vertically aligned. The less important functions are on the buttom left)

[Davide Casciato (casciade)]

I like 6b and 6b2, but it's more useful to choose the 6b1-prototype, because it fits into our general help-concept (better than the other ones ;-) ). In my opinion we shouldn't implement a new help-concept because of the usability. We've already got too many different ways to get help information (top of a dialog, bottom of a frame, ...).

[Johannes Wettinger (jojow)]

Look at p6b3 here! I think we can integrate the explanatory text as tooltips which will appear immediately(!) after you hover with the mouse over the button.
This is a really established concept to show explanatory information.

[Holger Röder (roederhr)]

@Johannes: in p6b3, the tooltip hides the third action. That's a common problem with large tooltips, so maybe we shouldn't go that way. I therefore prefer p6b1. (Though I guess we don't need 'back' and 'finish' buttons on the first screen.)

So maybe we can just agree on p6b1 and start drafting? :)

[Johannes Wettinger (jojow)]

Ok, from my side we can start drafting based on prototype 6b1.

[Davide Casciato (casciade)]

Unless there are no more suggestions from your side, we start from next week on with the blueprint for this feature.

[Daniel Kulesz (kuleszdl)]

I think we can still improve details of the feature later on. For now, p6b1 should be a great improvement upon the status quo, so let's start with the drafting and its implementation.

[Johannes Wettinger (jojow)]

As discussed internally, Davide is going to start creating the blueprint for this feature request, so he will be the drafter. If you agree, I'm going to take the approver role for this FR. ;-)

[Daniel Kulesz (kuleszdl)]

Yes sure, go ahead.

[Johannes Wettinger (jojow)]

FYI, Davide: There's already an existing blueprint which we can use for this FR:

https://blueprints.launchpad.net/revager/+spec/spec-redesign-first-screen

[Johannes Wettinger (jojow)]

Davide, thanks for creating the blueprint! I suggest to change the layout of the "open review" part a bit. Please find attached a modified version of the prototype.

[Johannes Wettinger (jojow)]

Now some feedback on the blueprint itself. :-)

1) I suggest to move the repository link (UI prototypes etc.) into the summary of the blueprint, because this is some static additional information which doesn't belong to the specification itself.

2) For the "REQUIREMENTS & SPECIFICATION" chapter I think it would be better to summarize the target as well as the requirements shortly; otherwise you always have to go through the whole discussion in order to get some basic information.

3) You don't have to link to the FR bug report because the blueprint is already linked to it. ;-)

4) For the "DESIGN & TECHNICAL SOLUTION" chapter we should definitely add some more information about the implementation details, e.g.:
----
The whole assistant dialog will be re-implemented. After removing the class 'org.revager.gui.dialogs.AssistantDialog', we are going to create a new package called 'org.revager.gui.dialogs.assistant_dialog'. The package will contain the following classes:

AssistantDialog (extends AbstractDialog) - the assistant dialog itself which contains one of the following panels
FirstScreenPanel (extends AbstractDialogPanel) - the first screen (see prototype)
OpenReviewPanel (extends AbstractDialogPanel) - the open review screen (see prototype)
AddAttendeePanel (extends AbstractDialogPanel) - the add attendee screen (see prototype)

The AbstractDialogPanel contains the following property 'private AbstractDialog parent' as well as the following constructor and method

public AbstractDialogPanel(AbstractDialog parent) { super(); this.parent = parent; }

public void setHint(String hintText) { parent.setMessage(hintText) }

and will be located inside the 'org.revager.gui' package. By this strategy we can access the description text area inside the dialog itself.

Inside the AssistantDialog class there is one private property for each "screen class".
----

What do you think? ;-)

[Johannes Wettinger (jojow)]

Just one correction: Instead of 'org.revager.gui.dialogs.assistant_dialog' we should better name the package 'org.revager.gui.dialogs.assistant' because for the protocol window we've named the package like this as well.

[Davide Casciato (casciade)]

Special thanks to you Johannes ^^ I've just copied the REQUIREMENTS & SPECIFICATION part out of your comment and inserted it into the blueprint. I don't think that any additions are necessary ;) Please add more comments if you notice anything else. I'm going to review your blueprint now.

[Johannes Wettinger (jojow)]

@Davide: No problem, I've just approved your blueprint. For the next step I suggest you as assignee for the implementation of this blueprint. You can create a new branch (from current trunk), assign the branch to the blueprint and start with the implementation. :-)