Printable View
This reminds me. Some people might find this fun, and it could help.Quote:
Originally Posted by Ghallo
Microsoft has a division that publishes design guidelines. It's a big document -- 800+ pages -- and it consists mainly of suggestions that have to be applied with judgment.
I usually try to follow it. If anybody wants to read it and help make Mojo stick to it better, that would be great.
Download at:
http://www.microsoft.com/downloads/d...3-1b9e8ea7fe8c
I have to write code in an efficient way. Sometimes that means the first iteration of a feature has to have a mimimum level of complexity so I can be sure the basic design will work for everything that it will be used for.Quote:
Originally Posted by Moorea
In this case, if I tried to write code that only handled DNP, it's extrremely likely that I'd end up throwing that code away and writing something new from scratch when I tried to add the other features we're talking about.
We have to back up and think about the problem in a very general way.Quote:
Originally Posted by Fursphere
Here's the deal.
Basically, this screen represents a lot of individual decisions. Each decision has three variables:
1. Which WoW has the focus.
2. Which WoW is the target.
3. Which key gets pressed.
These things are represented graphically as:
1. The WoW on the left.
2. The WoW on the right.
3. The line (row) of the spreadsheet.
To make this post easier to understand, let's pretend the user has five WoWs on the same PC.
There can be five WoWs on the left.
There can be five WoWs on the right.
In addition, the user might want to set a default for any WoW being on the left.
In addition, the user might want to set a default for any WoW being on the right.
That's 36 permutations.
I've said a couple of times that I think the program should use the metaphor of "nested" settings to simplify things, where one setting is a default and another setting "inherits" and "overrides" the default.
I know this sounds jargony and complicated but the idea is actually simple, and if it's used throughout the program, and if the screens represent the idea in a good graphical way, I think it might be the easiest thing.
So here's what I'm coming up with.
Fursphere's drawing gets simplified. It has a new basic form with only two columns. The column on the left is the default for the focus WoW. The column on the right is the default for the target WoW.
In other words, if the user only uses those two columns, they define what happens when any WoW is in the foreground (left) and what gets received by all WoWs (right).
But if the user wants, he or she can add columns on either the left or right for individual WoWs.
Once columns are added, the user can click on them to highlight them.
When that happens, it sets the permuation for the entire table.
Actually I'm not sure that works -- I need to drink a cup of coffee and draw some examples. :)
There's a problem with the scheme I just outlined, but it has two possible resolutions.
Suppose the user defines the key mapping for a particular key with WoW1 on the left and default (any WoW) on the right.
And suppose the user defines the key mapping for that same key with default (any WoW) on the left and Wow2 on the right.
Now he's playing. WoW1 is in the foreground. He presses that key. What gets sent to WoW2?
Mojo looks at its settings to answer that question. Unfortunately it discovers that there are two different answers. One answer is the setting in "Default left, WoW2 on right." The other answer is the setting in "WoW1 left, default right."
(If the user defined a setting for "WoW1 on left, WoW2 on right", there isn't any problem, but let's supposed he didn't.)
How does Mojo pick one of those two solutions?
Either Mojo resolves the ambiguity by choosing the setting that is more narrowly defined on the left (in other words, it cares more about the foreground than the target), or else Mojo looks higher in the inheritance hierarchy and uses the "default on left, default on right" setting.
You and I are probably thinking the same thing right now. This is way too complicated. This is nuts.
But I don't know how to avoid this.
Because this "problem" is just math. If the program allows people to choose these settings, then mathematically, this problem arises. It's not part of the way we're drawing the screens or anything like that.
Reactions, please! :)
Edit: Another possible solution would be Mojo to look for ambiguities of this sort when the user changes settings. If Mojo finds one, it highlights the key mapping and asks the user to choose which mapping to use.
This is how programming tools handle this kind of problem . But this seems awfully complex and confusing for the average multiboxer.
This is why I spoke "DNP" list first, "keymaps" second. A DNP list can be static and simple - you don't have logic loops.
Foreground WoW takes priority, and thats it.
You could probably write some code to check for logic loops - and in the even of one happening saying "hey dummy - check your keymaps!" :) but thats more work.
Edit:Quote:
Originally Posted by Fursphere
I have to figure out the design of the whole thing before I write code for the simplest case.
Otherwise, like I told moorea a few minutes ago, that would be more work for me, not less.
As far as that goes, that's fine, but the user might want to define things more narrowly and the program has to make clear in some comprehensible way how to do it.Quote:
Foreground WoW takes priority, and thats it.
It's not any more work because it's basically the same work the program will do every time you press a key.Quote:
You could probably write some code to check for logic loops - and in the even of one happening saying "hey dummy - check your keymaps!" :) but thats more work.
Edit: This is a microscopic amount of work for the CPU. It's complicated to explain but it's the kind of thing that takes very few CPU cycles.
How about we separate the WoWs from the columns. Then we always have two columns and the screen looks simpler. People could pick the WoWs from a drop down lists (as shown here) or I could make litte rectangles with an icon for each WoW.
The right hand column is color-coded to indicate whether the setting is inherited from a "higher" screen or whether it was set on this one.
Edit: red could be used to indicate ambiguity, but if the user ignores red, the program would use the "left-first" rule described above.
Edit: By the way, for peope who are thinking this is too complicated, this screen is all that most users need to look at.
http://mojoware.org/art/keymap.gif
Your design was so confusing to me that I didn't understand what it did even after I asked you to explain three or four times.Quote:
Originally Posted by Ghallo
consider KISS principle :-) for 99.9% of users and case; the only thing you need is
- all the keys always go to the window where the mouse is
- some keys (the DNP) don't go to all the other windows
if you can do the more complicated cases above while still preserving this use case simple to achieve, then the more power - otherwise split the ui so the above is ez to get (and hopefully we can get that faster than the rest :-p)
ps: the spreadsheet was scary
How about we work on the design for a single window for a while and see how easy we can make it.Quote:
Originally Posted by Moorea
Which spreadsheet? Fur's or mine?Quote:
ps: the spreadsheet was scary