On Mar 2, 2010, at 7:49 AM, bulia byak wrote:
2010/2/24 Krzysztof Kosiński <tweenk.pl@...400...>:
"User experience" is not a concept that can have its dedicated object
- every line of code in the program affects it. Similarly you can't
have meaningful "UsabilityManager" or "InkscapePopularityBooster" classes. What does "managing the user experience" actually mean? I am afraid that this class will quickly become a bag of unrelated things or a God object. There should be a better name for it, for example "ToolbarLayoutManager", "TaskManager", "CommandSet" or "TagStorage".
I agree with Krzysztof here. Jon, to me "user experience" is an almost meaningless marketing phrase. Could you try and find something better?
Well, it's not a marketing phrase.
It's now the industry standard (human interface design, HCI, HIG, etc, industry) for what is being addressed.
http://en.wikipedia.org/wiki/User_experience
So any people who work or even look into usability are using that. Most people working in usability are addressing "UX". The term has moved in to the mainstream on that front. Most people I've talked with at conferences, etc, for the last two years now has been speaking of "usability" and "UX".
By the way your "eek" files, still in the codebase, are not exactly a good naming example either, even if you invent a backronym for them :)
Yes. Though I did have an acronym for them from the beginning. Once we open things up again I'll go through and get those renamed with "ege".
For icon preview and RSVG preview, I see no reason to have an extra class to create them - just create a preview dialog in response to action activation like any other. Docking would be better left to GDL and the user (unless you have some specific examples where something more complex needs to be done). Moving windows is a bad idea - the window manager should do it.
We have something similar for normal and fullscreen modes: the set of visible toolbars and other elements is different and independently remembered in these modes. In any case, this code should then be combined with the new "ux" code.
Yes, exactly. As soon as I have a break in coding I was going to explain to Krzysztof about "*Manager" being the common naming for a facade pattern, and how employing such design patterns can be helpful.
The very tricky part here is to layer things up properly so we can gain the most. We very much need to get "business logic" out of the toolbar code and change from so much of the hardcoded support we have now (where even some widgets getting displayed initialize internals that otherwise are left random) and get a proper distribution of responsibility.
To address the specific there, the "fullscreen" boolean is just one aspect in the current UX set. Those will need to be combined and managed in a data-driven manner. Otherwise the combination of settings will explode.
For user setting persistence we have preferences - it's better to add whatever functionality you need to them. The logic to determine where the toolbars should be by default based on screen resolution can be put somewhere in the toolbar creation code.
Definitely, all UI for this feature, whatever it is, should be in Preferences.
Somewhat...
The preference mechanism is good for storing sets of data, but hooking it in to the low-level of each widget construction function is not how we should implement it. Basically Krzysztof seems to be thinking here of here of spreading the business logic throughout all vertical layers, whereas what we need is to think of things more in an N-tier architecture type of approach with the UI cleanly separated from such decisions.