Help designing the evolve UI

[Pierre-Yves David]

On 04/15/2014 01:12 PM, Jordi Gutiérrez Hermoso wrote:
> So, I have started a wiki page to discuss the design of Evolve:
>
>      http://mercurial.selenic.com/wiki/EvolveUI
>
> Please add to this page with whatever additions. concerns or ideas or
> suggestions you may have for the Evolve UI.

1. I would like to thank Jordi for starting this discussion. The UX is 
an important part of evolution and I've barely any time to devote to it yet.

2. The goal of this pages is to sum-up main argument, proposal, use case 
for various subjects. We need something with more structure. Something like:

  * Glossary,
  * Existing Commands
    * Summary of existing commands and alias
    * One section per command//action
      * Quick reminder of the command//action role and spirit
      * Discuss for name change
      * Discuss flag names
  * Behavior: all topic related to changes/improvement of behavior
    * One section per topic
      * Quick summary of the issue
      * Summary table of options
      * Detailed behavior and arguments for each options
  * User case
    * one section per use-case that needs improvement.

On a general basis: this page also needs more tables and less walls of text.

Some organized way to attach names to proposal (and votes) would be nice

3. The goal of any discussion on this list is to get material to fill 
this page. Then we can take proper decision later. Please update it 
whenever a good argument/proposal/use case show up.

4. This email thread is not the alpha and omega of evolve UI 
discussions. The discussion is too big to fit in a single discussion. 
This thread is -already- too big. Please scavenge any good elements from 
it to update the list. Spawn a new threads on a restricted topic if you 
want to discuss something further.(And make sure to limit your rate if 
you want other peoples to follow).

5. No, we are not going to decide to automatically evolve everything all 
the time. The step by step approach is very valuable and I would like 
every early user to discover that before trying to do anything else.

6. If your proposal involves stripping obsolescence markers I do not 
want to read any of it. Just defining your use case is perfectly fine. 
(Note that better support for aborting multi-step operation is different 
than stripping)

7. This email is too long already

Thanks all for your interest in evolve. I how to see this wiki page grow 
and flourish!

-- 
Pierre-Yves David