Open GoogleCodeExporter opened 8 years ago
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
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
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
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:
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
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:
I'll be happy to tackle this one.
Original comment by jeff.dil...@gmail.com
on 1 Nov 2010 at 6:24
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
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
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:
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:
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
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
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
[deleted comment]
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
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
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
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
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
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
"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
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
I can QA these changes if needed.
Original comment by jeff.dil...@gmail.com
on 15 Dec 2010 at 12:39
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:
[deleted comment]
Great I love it!
Original comment by netpr...@gmail.com
on 28 Dec 2010 at 1:28
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
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
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:
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
Original issue reported on code.google.com by
netpr...@gmail.com
on 20 Oct 2010 at 5:47Attachments: