GUI simplification proposal (includes a mockup)

[GoogleCodeExporter]

Here is an idea I've been having about a possible user interface for the 
evolution chamber.

Currently the UI consists of many widgets that are not used in a typical use 
case scenario. Most users define two or three targets (upgrades, unit mixes and 
buildings) rendering the rest of the widgets not used and obfuscating the 
layout (people have to search for specific fields).

I propose splitting the entry into two data tables. One for way points and the 
second for steps defined in each waypoint. Data in the entry grids would be 
editable inline (upon double click the label changes into a drop-down/text 
entry field).

The Start / Stop button is merged and the Restart button is completely dropped 
(as a quick double press on the Start/Stop button results in a Restart action. 
Am I correct?).

Two additional widgets are provided for exporting the generated data (a 
drop-down selection of the format and the export button).

This is of course just a proposal on my part and I'm open to any questions :)

Original issue reported on code.google.com by netpr...@gmail.com on 20 Oct 2010 at 5:47

Attachments:

• evolutionchamber-gui-proposal.png

[GoogleCodeExporter]

I like this. The only thing I would like to revisit is the drop-down. Maybe a 
breakout panel that when you collapse it collapses into the list form. 

The design reason for this is to build familiarity with a static UI, and lists 
break that, because they are impossible to use muscle memory to learn, one must 
always search the list using a combination of the mousewheel and sight.

Original comment by Frit...@gmail.com on 21 Oct 2010 at 1:24

[GoogleCodeExporter]

This looks awesome, I'd definitely prefer this.  Much more simple to manage 
than the dozens of confusing combo boxes.

Original comment by insolen...@gmail.com on 30 Oct 2010 at 11:35

[GoogleCodeExporter]

I'm going to branch the trunk and try to implement this.
I'll submit the branch for code review later on when it's done.
This issue may be updated with more information as I work on the issue.

Original comment by netpr...@gmail.com on 30 Oct 2010 at 12:01

• Changed state: Started

[GoogleCodeExporter]

New GUI proposal.
 * Added deadline to the waypoint table.
 * Added type selection for the targets to reduce the amount of options in the target drop-down.

Original comment by netpr...@gmail.com on 30 Oct 2010 at 12:45

Attachments:

• evolutionchamber-gui-proposal_2.png

[GoogleCodeExporter]

Just a note: In the proposals I upload the current state of the GUI is not 
included the setting tabs, new buttons etc). Those things will not be changed 
and my main target here will be the implementation of the data entry tables on 
the left.

Original comment by netpr...@gmail.com on 30 Oct 2010 at 12:54

[GoogleCodeExporter]

Just uploading a snapshot of the current state the new GUI.

Original comment by netpr...@gmail.com on 30 Oct 2010 at 6:40

Attachments:

• ec-new-gui-snapshot-1.png

[GoogleCodeExporter]

I'll be happy to tackle this one.

Original comment by jeff.dil...@gmail.com on 1 Nov 2010 at 6:24

[GoogleCodeExporter]

Feel free to commit changes directly to the branch.
The main goal is the new tables as input method. We shouldn't remove any 
ongoing functionality like the export/simple format/copy buttons.
The old tabs should remain functional at least for the initial release, so a 
new settings option to switch between the old tabbed waypoints to the newGUI 
single tab.
The last part is open for discussion (switching modes).
I'm still learning Java and Swing so my current implementation has some 
problems. I tried to note them out both in the code and the commit messages.

Original comment by netpr...@gmail.com on 1 Nov 2010 at 7:24

[GoogleCodeExporter]

Cool Thanks. I'll take a look tonight. I didn't get a chance to last night.

Original comment by jeff.dil...@gmail.com on 2 Nov 2010 at 6:33

[GoogleCodeExporter]

While I agree that there is room for improvement, the current UI is less 
cumbersome than the proposed mock-up. 

The current UI allows you to quickly change any unit count with 1 click and 
1||2 keypresses for the amount. This means at most 3 interactions per change.

The proposed UI would require 1 click to add a new target, 1 click + scrolling 
to find the type, 1 click to select, 1 click focus + scrolling to find the 
unit/structure/upgrade, 1 click to select, and then 1 click and 1||2 keypresses 
for the amount. This means 6-7 interactions, not even counting the scrolling 
which is a huge bottleneck on interaction speed for any list of length > 5.

In the case of something like an upgrade, the current only takes 1 click to 
toggle, and would require many more selections to add in the proposed UI.

The current UI should merely be re-organized, possibly adding icons for 
increased visual acquisition speed.

Attached an example of what I mean. This is just a small section, Structures 
would be a category as well, and of course you need the other parts of the 
interface such as waypoint management.

Original comment by hugh.lo...@lodestarbpm.com on 2 Nov 2010 at 7:55

Attachments:

• example.png

[GoogleCodeExporter]

To expand on the above, if you add an up/down scroller to the input boxes you 
can reduce the interaction to a single click in the case of units you only want 
a low number of, such as a hydralisk den. Keeping it an editable text field 
allows for the flexibility, while the arrows provide ease of use for the common 
case.

(The white thing is a mouse cursor)

Original comment by hugh.lo...@lodestarbpm.com on 2 Nov 2010 at 8:10

Attachments:

• example.png

[GoogleCodeExporter]

I like this approach but how will it scale to more races and a variable number 
of waypoints?

Original comment by netpr...@gmail.com on 2 Nov 2010 at 9:01

[GoogleCodeExporter]

Have a zerg tab, a protoss tab, and a terran tab. 

Waypoints can just be a selectable list on the left. Waypoint 1, Waypoint 2, 
etc.

Original comment by hugh.lo...@lodestarbpm.com on 2 Nov 2010 at 9:35

[GoogleCodeExporter]

We need use cases (user stories) for 2 or 3 build orders for each race. I'll 
make the necessary UI changes if someone wants to write these out. I think it 
will help plan things out.

Original comment by jeff.dil...@gmail.com on 2 Nov 2010 at 9:38

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I may be able to create those today or tomorrow evening. We'll see.

Original comment by hugh.lo...@lodestarbpm.com on 3 Nov 2010 at 2:30

[GoogleCodeExporter]

The new GUI is really bad... All users under 1440px screen width can't see the 
starts buttons... Can we just get the old sources of the working GUI?

Original comment by maximve...@gmail.com on 7 Nov 2010 at 12:41

[GoogleCodeExporter]

Which new GUI? I haven't made any changes yet. Although it seems like someone 
else branched and is taking care of this (don't have the link with me), which 
is what I'm assuming you (maximveron) are referring to. 

If someone wants to come up with a several use cases as outlined above, then 
I'll be happy to get started on this. I just don't want start this blindly 
without any sort of direction or knowing how it's likely going to be used.

Original comment by jeff.dil...@gmail.com on 8 Nov 2010 at 11:46

[GoogleCodeExporter]

maximveron to which version of the application are you referring to? Changes 
discussed in this issue aren't included in any releases and the main 
development branch.

Original comment by netpr...@gmail.com on 10 Nov 2010 at 1:32

[GoogleCodeExporter]

When(if) the time becomes available I'll come up with a couple use cases myself.

Original comment by jeff.dil...@gmail.com on 10 Nov 2010 at 8:33

[GoogleCodeExporter]

Yeah I apologize for not hitting it yet, I will this Sunday.

Original comment by hugh.lo...@lodestarbpm.com on 12 Nov 2010 at 5:50

[GoogleCodeExporter]

"We need use cases (user stories) for 2 or 3 build orders for each race."

I think that we should just focus on Zerg for now, since that's all that EC 
supports at the moment.

Original comment by mike.angstadt on 17 Nov 2010 at 4:08

[GoogleCodeExporter]

The other races are in the works and will be done shortly from what I've 
gathered hanging out in #EvolutionChamber on quakenet. Planning for them now 
will help immensely a bit later. Although Zerg should definitely be done first.

Original comment by jeff.dil...@gmail.com on 18 Nov 2010 at 11:39

[GoogleCodeExporter]

I can QA these changes if needed.

Original comment by jeff.dil...@gmail.com on 15 Dec 2010 at 12:39

[GoogleCodeExporter]

I created a new GUI based in part on netprobe's design.  It allows the user to 
view all waypoints at once, making it easier to see the entire build order in a 
single glance.  Each waypoint has a table that lists the units, buildings, and 
upgrades that the waypoint targets.  Waypoints can be easily added and removed. 
 Other changes include:

* Adding a Race dropdown list which we could use to allow the user to switch 
between races once we have support for Terran/Protoss.
* Improving the auto-updater by allowing the user to cancel the update check 
operation and the download operation.
* Adding "help" icons, which give a brief description of the input field that 
they are associated with.
* Validating input fields.  For example, only allowing numbers to be entered 
into the "Processors" textbox.
* Allowing the user to give names to the build order and waypoints.
* Using a new layout manager called "MigLayout".  I think this is a lot easier 
to work with than the GridBagLayout, which is what the old GUI uses.  There's a 
lot less code you have to write.  Instead of creating a GridBagConstraints 
object for each component, you just create a single String with all the layout 
properties.

Some things that still need to be done:
- Fix the finicky nature of the dropdown list in the waypoint table.  Under 
certain circumstances, the wrong dropdown list is displayed (for example, it 
sometimes displays the units dropdown list when it should display the upgrades 
one).
- Externalize hard-coded strings.
- Test the application on multiple OSs.  I've mostly been testing it on my Mac. 
It probably looks slightly different on other OSs, which could effect the 
functionality of the application.
- Use colors that match the current OS.  Currently, each waypoint uses 
hard-coded background and border colors, which may not match the color scheme 
of the rest of the application, depending on the OS.
- Test for bugs.
- More??

I put this in a new branch called "NewGUI2".  I didn't want to use the existing 
"NewGUI" branch because it's very outdated, which would make merging it into 
the trunk more difficult.  Most of the new code is in the 
"com.fray.evo.ui.swingx2" package, but I had to make a couple changes to some 
other files throughout the codebase.

Let me know what you think!! :)

Original comment by mike.angstadt on 27 Dec 2010 at 7:50

Attachments:

• ec1.png
• ec2.png
• ec3.png

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Great I love it!

Original comment by netpr...@gmail.com on 28 Dec 2010 at 1:28

[GoogleCodeExporter]

Awesome dude! Thanks! I'll take a look as soon as I can and report back any 
findings.

Original comment by jeff.dil...@gmail.com on 4 Jan 2011 at 7:48

[GoogleCodeExporter]

Thanks, I'm glad you like it. :)  Let me know if you find any bugs or if 
there's anything you think can be improved.

Original comment by mike.angstadt on 9 Jan 2011 at 9:49

[GoogleCodeExporter]

Wow! Now that I see it running I'm even more impressed. This should definitely 
go mainstream as soon as possible.

Original comment by netpr...@gmail.com on 13 Jan 2011 at 6:31

Attachments:

• ec-new-gui-2-vista.png

[GoogleCodeExporter]

There are still a number of things that need to be fixed, so replacing it with 
the old GUI, if everyone agrees with this change, is still a ways off.

Original comment by mike.angstadt on 14 Jan 2011 at 6:50