Quote:
That interface reminds me of a development environment the electrical engineers used to use. As soon as a project becomes reasonably large it starts looking like a total cluster coitus. I'm not convinced it's the next-gen desktop environment. Windows are a nice paradigm. And for development my two main issues are 1) clutter and 2) difficulty expressing certain concepts within the framework of linking modules together.
Bingo. Navigation and no-hassle cluster manipulation are some other problems. They don't have a coherent shortcut scheme, given that you are provided "infinite space." Mere bookmarks definitely will not work.
I'll probably find it annoying to use if they don't at least address those issues. As for linking modules, I think the best direction for a modular/procedural authoring scheme is a combination of ~~
1. Uniform orthogonal layouts for micro-managed atomic workspaces. Think of spreadsheets [data-oriented] or werkkzeug [procedure-oriented]
2. Arbitrary containers that nest content into non-uniform orthogonal meshes for the macroscopic framework; equivalent to GPG's work, but using orthogonal meshes rather than floating windows i.e. modules always make orthogonally-adjacent connections. One big problem is how these are manipulated. You can't argue that floating-windows are more intuitive to manage as long as these
ortho-windows are not managed with immediate drag on drop. A drag and drop scheme can still be implemented to function intuitively, but will probably only function elegantly on an intermediate domain (i.e. think contrary to WYSIWYG).
Whereby this combo exists within an infinite workspace environment that is ultimately controlled by some kind of hierarchical-relational scheme which effectively increases the coherence of manipulation and defines the basis of filtering.
Here is an excerpt from my work-in-progress essay on tool design:
=================================================
Exhibit 4
Now let's look at .werkkzeug (apparently with one less k, 'werkzeug' is German for 'tool'!)
Introductions:
http://wikibin.org/articles/.werkkzeug.html,
http://theproduct.de/tool.html,
http://web.archive.org/web/201107170250 ... werkkzeug1, and http:// llg.cubic.org/docs/farbrauschDemos/ (start reading from at least "The procedural Idea").
I can't find any easily-accessible demonstrations of it, so just download it here to see what it is like (it's small):
http://www.farb-rausch.com/prod.py?which=113Also, please watch this video (though it's 63 MB) to get an in depth explanation of .werkkzeug:
http://www.scene.org/file.php?file=%2Fp ... i&fileinfoAs you will hear later in the video @ 30:07 (after his portion on .werkkzeug), I also completely agree with Chaos's opinions on user-interface design. For those who don't want to download the video, I've rewritten the first and most important slide from this part:
About GUI Design- Overlapping windows are evil. (Arrange windows with splitters)
- Icons don't make things better. (Usually they are meaningless when you see them for the first time.)
*He says textual labels are better.- Don't use Windows [Win32 API, native GUI-libraries etc.], code your own GUI-library! (In the end, this will save a lot of time!)
*He makes some good points about the complexity of customizing/re-targeting pre-existing GUI systems in contrast to introducing a unique solution. Personally, I also think Window's native GUI always sucks anyway. You will also find that bugs are abundant with GUI-libraries such as Win32.- Don't hide complexity. (Let your GUI match your data.)
[There are more slides, but they're about more minor/particular design principles. I recommend you just download it and watch the entire thing]
I would like to make an addition to his opinion regarding complexity -- which I completely agree with; I hate it when I have to navigate through an unnecessary organizational scheme every time I want to work with one element, or when I'm completely unable to manipulate such properties:
It helps to find a scheme that contains such complexity without having to distribute it i.e. I see no problem with reduced interfaces, as long as they apply to forms of manipulations which may be reduced naturally -- perhaps in a more ideal approach with a better fitting model. For instance: In Blender, I think materials would be much easier to create if their control-model explicitly respected anisotropic BRDF data. Stacking various predefined BRDF models and tweaking their parameters is unnatural, limited and very hard to work with. This solution might actually introduce physically based material design i.e. real material properties involving particulate compositions, gels/liquids etc. which serve as an abstraction corresponding to micro-facet theory, though not disturbing complexity as much as generalized BRDFs.
Quote:
Christ Taylor
Correction: Almighty Jesus Taylor!
Login
Register
FAQ
Search
