Pavel, you might find these findings related to your goals, at least to the process involved in achieving them: "New Approach to Designing Visual Notations" (http://www.sciencedaily.com/releases/2013/07/130718161429.htm)
On Sun, Jul 21, 2013 at 9:38 AM, Pavel Bažant <[email protected]> wrote: > > > There are various ways to present the same structure. >> Trees, for example, can be represented top-down, bottom-up, >> left-to-right, dynamically (front to bottom), graphically, textually, >> etc. Each representation can also lead to different ways of editing >> them. So each application wants to represent them in a certain way. > > So you can have a toolbox of tree representations and editing modes, but >> don't count on having a single one to serve all the applications. >> > > Yes, I agree. But that's just what I had in mind with the pixmap editor > example -- the editor provides a specialized pixamap drawing interface, but > the idea was the general array editing capability provided by the OS shell > to be applicable *uniformly* to any array-like structure in any > application, i.e. to the pixmap, too. This way any generic array > manipulation tools I may have created for myself have much broader > usability. The whole environment (OS + applications) would be "structure > centric", not "bytestream centric". > >> >> >> And this problem is compounded by the number of different data >> structures. >> > A nD array and a tree cover 80 % of structures the user conceptually works > with. Add DAGs and a few other types of graphs and you are at 90 %. > Moreover, specialized views can often be ambiguous, whereas the generic > ones wouldn't be ambiguous. > >> >> >> > 3) Get rid of established but unnatural ways of manipulating data. >> > Most importantly, get rid of flat text and find neat graphical >> > representations for the most common structures. >> >> Bouhahaha! >> >> I mean, graphical representations are nice. To read them. But when it >> comes to editing, ie. to transfering information from the human brain to >> the computer, nothing beats in bandwidth the ten fingers and the >> ~100-key keyboard. >> >> I am sorry, my wording was not exact. I meant to say find neat generic > graphical *presentations* of structures and edit the structures directly, > not their on-disk linear representations. I didn't say anything about input > methods. There is no reason why one couldn't directly and very efficiently > edit structures using a keyboard. Such systems actually exist, but I think > they are underused in the programming community. > > >> Unless you want to develop high resolution brain waves reading systems. >> > > This would be nice, I could then prepare my answers in advance. > > >> The point is that you can't think like that, in such general terms, for >> all applications and for everybody. > > > Yes, I use very general arguments, so there is greater risk of missing > important details. At the same time, there is higher chance of finding new > ways to simplify all this stuff. Software development is a disaster today > and the various tools constantly emerging are actually just masking the > real problems, making really effective solutions even less likely. > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
