Use Cases for proposed user interfaces - add your own design ideas, or criticize others'



  • Thelema UI, case 1: A novice (with other computing experience) learning the basic interface.
    A new office worker has come on board with a company that is using the new user environment. While he's an expert in calculating and explaining the various issues regarding fuel economy in vehicles, and can easily write a simple report on the efficiency of an existing fleet and possible ways to improve the fleet efficiency using the familiar tools (e.g., MS Word), he hasn't worked with the specific system before.

    It is explained in simple introductory tutorial that help and extended documentation can be found by right clicking to bring up a dialog menu, and selecting 'help' (this is just one possible interface, postulated for the sake of argument; I'll use the term 'rc' as shorthand for right clicking, though the docs wouldn't in real life). The menu is a bit intimidating due to the unfamiliar set of default options, but 'help' is clearly marked so he finds it easily enough. According to help, in order to create a new document, he should rc-> new document, which will open a new document window with... nothing in it, and no obvious interface except a top menu with only a copy of the Help link in it. Checking help again, he finds that he should be able to simply type text into the window, but it recommends that he choose a layout. It says that to choose one, he should rc-> open tools and select a layout 'named 'Word Processing' from the list.

    The default toolkit has two lists, one of layouts and another of tools. The default list of layouts includes one for general word processing (as the help menu mentioned), so the user selects that. This changes the current empty main menu to one populated with general editing tools, and adds a speed bar for commonly used tools as well. Because the layout is specifically designed to be similar to those found in more conventional word processing tools, and the current instance has't been modified, it should be familiar enough for the user to begin editing the document. Since editing is journaled and auto-saved, there is no need to save; changes go into the stream of links rather than changing the text, but to the user, it seems little different from, say, MS Word.

    OK, so that may seem like lot of work to do just to get started on a text document, especially since the interface ends up looking vaguely like a familiar one, but you have to also consider that, for a novice user to be able to begin using an unfamiliar system's word processor, without knowing an application's name or interface, it is quite smooth. I'll admit I hand waved the difficulties, as well, but I'm trying to make a general point about being able to get started quickly even when unfamiliar with the tool set. Did I assume that they knew at least one other system's word processor already? Sure. Could I have started with the assumption of zero knowledge of computers? Yes, and I would love to go back at some point to address that possibility. This is just the first go at explaining the ideas behind it.



  • Do you force use of contextual menus? What if the user has a 1-button mouse (or is only physically-capable of using 1 button)? What if they're using a Wacom tablet, or tablet PC?



  • I'm not sure yet; probably not, though they are one of the possibilities I've been considering as a basic tool. As I said, this was mostly for explanation purposes; the actual UI won't necessarily work the way I describe it now. On the one hand, contextual menus are both clean and (in this case) easy to describe in words. They do, however, require a specific tool to use easily (a mouse with at least two buttons), and are awkward for single-button mice, trackpads, etc. I doubt i'd make them quite so central as I describe it here; it was just one of the possibilities I've had in mind.


  • Discourse touched me in a no-no place

    @ScholRLEA said:

    Since editing is journaled and auto-saved, there is no need to save; changes go into the stream of links rather than changing the text, but to the user, it seems little different from, say, MS Word.

    That's a good choice (especially if you can couple it with deep undo) though quite a break from what most word processor users are used to. The only system that they're likely to have encountered that works that way is Google Docs (maybe some of the Microsoft online tools work that way too; I've not seen them and have a requirement for working entirely offline1 for my own office-suite use).


    1 I'm necessarily networkless for quite a large fraction of most days, because WiFi signals don't propagate well through solid rock.



  • @dkf said:

    WiFi signals don't propagate well through solid rock.

    Or lathe plaster w/ chicken wire on every fscking wall/ceiling in the house.

    I have nice coved ceilings in every room 'tho… and 3 wifi boosters. In a 1½ storey house.



  • Two things that I would like to see more of in linux gui design are: better access to the shell commands that are being executed by the program, and an intuitive visual language for piping/streaming data from one program to another.

    To illustrate what I mean I'll describe the toolkit that all this talk about use cases and the survival of the shell and whatnot has got me daydreaming about. The brief description of this toolkit would be “automatically translates certain types of shell scripts to gui controls”, although it would have more uses than just that.

    The shell scripts that I am thinking of are basically just simple wrappers around command-line programs, and have the form: assign variables, validate, execute command. Each variable would have an auto generated ui input control, validation would be executed as appropriate, and ‘execute command’ would be linked to a big glowing GO button at the bottom of the control. Every control would have (I'm thinking beside or below the minimize/maximize/close buttons) three buttons: show the current version of the script, show recent changes (ie a ui event stream), and show the stylesheet (allowing a user to change the way their control is displayed).

    More complex scripts would be created by stacking controls: connecting the top of one control to the bottom of another, merging them into the same GTK/QT/Whatever window. There would presumably only be one GO button per window, executing each control's script in order. The left and right sides of each control would represent the stdin and stdout streams, respectively; stacking controls horizontally would be similar to stacking them vertically, except their scripts would be connected by a ‘|’ instead of a ‘;’ To improve flexibility, we could add a way to connect controls in this without requiring them to be stacked physically adjacent to one another. The visual language we would use to show linkage in this case would come in handy when we want to add backtick-style functionality for linking a programs output to a specific field within a control rather than directly to stdin.

    The idea is that each program in /bin or wherever would be directly associated with a control, and that complex scripts could be composed by connecting controls to one another, and the whole composition could be saved as its own shell script or ui program.



  • @Buddy said:

    The shell scripts that I am thinking of are basically just simple wrappers around command-line programs, and have the form: assign variables, validate, execute command. Each variable would have an auto generated ui input control, validation would be executed as appropriate, and ‘execute command’ would be linked to a big glowing GO button at the bottom of the control.

    It kind of reminds me of SSIS, and I really hate SSIS. And even then, I see more point in it than in this solution (given that you can't pipe stuff in C# that easily, as opposed to bash).


  • Discourse touched me in a no-no place

    @Buddy said:

    The idea is that each program in /bin or wherever would be directly associated with a control, and that complex scripts could be composed by connecting controls to one another, and the whole composition could be saved as its own shell script or ui program.

    The best thing I've seen along those lines was AVS/Express. It didn't do exactly what you ask for — it was much more focussed on its problem domain — but it was the most tremendously usable way of graphically constructing programs out of components, producing clear illustrations of what was going on while enforcing relevant type restrictions in a comprehensible fashion. (We used to have a site license and handle their academic support in the UK. Not any more, not for years…)

    However…

    The hard part of working with a graphical programming language is making the damn thing scale. It's much easier to make a textual programming language understandable as the programs get large and complicated than it is to do so with something entirely GUI-driven, so much so that I've yet to see a particularly good answer there.



  • @dkf said:

    The hard part of working with a graphical programming language is making the damn thing scale. It's much easier to make a textual programming language understandable as the programs get large and complicated than it is to do so with something entirely GUI-driven, so much so that I've yet to see a particularly good answer there.

    Exactly. I've spend quite some time making projects with something like that. You had a visio like interface where you dropped blocks on the canvas, configure the blocks, connect them and let the server run it. The idea was nice for entry level stuff but quickly spiraled out of control for more complex projects.
    For the GUI to remain readable every block only has place for few characters, say 8 or 10. This means that 'functions' like GetUserPermissions and GetUserPostalAddress would both look like GetUserP in the interface. Ofcourse you'll put all actions pulling user info from the db close to each other leaving you with a series of block with similar names.
    Common control structures you use daily (loops, if, case, conditional stuff) can be hard to express in a graphical way without getting messy, taking up a huge space or both.



  • @dkf said:

    That's a good choice (especially if you can couple it with deep undo) though quite a break from what most word processor users are used to.

    This. Journaled editing is a very powerful way to implement undo/redo, even. Most application file formats either don't get along with it well or hand-roll it badly, though; I'd strongly recommend using a RDBMS-in-a-file solution such as our old friend SQLite for the file format if you wanted to do this.

    @Buddy said:

    an intuitive visual language for piping/streaming data from one program to another.

    Yeah. Linux needs something akin to AppleScript for gluing GUI programs together, even though it wasn't visual. I'm not sure how far the toolkit authors would get on board with this idea, though; there are probably pieces of what's needed in GTK and Qt already, but not nearly all of it.


  • Discourse touched me in a no-no place

    @tarunik said:

    Linux needs something akin to AppleScript for gluing GUI programs together, even though it wasn't visual. I'm not sure how far the toolkit authors would get on board with this idea, though; there are probably pieces of what's needed in GTK and Qt already, but not nearly all of it.

    I'd fully expect them to engage in megaphone standardisation: shouting at everyone else to do it the way that they're using internally.



  • I think they should implement something like this just so we can see what horrible disaster they end up with, and can point and laugh.



  • @Maciejasjmj said:

    (given that you can't pipe stuff in C# that easily, as opposed to bash).

    Bash, yes, but not X11, is the point I was trying to make: in linux, any time you want to do something serious, you have to drop to cli. In my imagination, a cool thing that could happen is:

    • user googles some problem, receives a couple lines of code to solve the problem
    • user pastes the code into a launcher
    • code is auto translated to gui elements, with help text and tooltips as necessary
    • user can see more easily what will happen when clicking go, gaining comfort with linux and a bit of familiarity with bash scripting in the process

    Side Note: @ScholRLEA I think a good idea for any context-sensitive help system would be to support wiki-style editing of the help text and a q&a system from directly in-app.

    @dkf said:

    The hard part of working with a graphical programming language is making the damn thing scale. It's much easier to make a textual programming language understandable as the programs get large and complicated than it is to do so with something entirely GUI-driven

    Encapsulation. I like to joke that Quartus is the best IDE I've ever worked with, because you can freely intermix block diagrams, code, graphical state machines, etc, including them into each other as appropriate. To be honest, though, I'm probably in the same camp as you, as far as preferring text over diagrams goes, but a lot of the people I've worked with like them.

    @Luhmann said:

    Exactly. I've spend quite some time making projects with something like that. You had a visio like interface where you dropped blocks on the canvas, configure the blocks, connect them and let the server run it. The idea was nice for entry level stuff but quickly spiraled out of control for more complex projects.

    Encapsulation. Continuing on from before: while I don't particularly enjoy graphical programming environments (at least not any of the ones I've ever used), there is definitely an argument to be made that what you're talking about is actually an argument in favor of graphical programming: you are forced to confront your own spaghetti.



  • This post is deleted!


  • @Buddy said:

    Bash, yes, but not X11, is the point I was trying to make: in linux, any time you want to do something serious, you have to drop to cli.

    And that's fine, because writing text is way more freeform and easier than arranging blocks. Case in point: in Poland, we tried to teach kids programming on this thing:

    http://cacheee.ovh.org/Szablony/eliobszarrpacy.jpg

    Now imagine making an enterprise system using it. AFAIK it's Turing-complete, so have a go.

    @Buddy said:

    In my imagination, a cool thing that could happen is:

    user googles some problem, receives a couple lines of code to solve the problem
    user pastes the code into a launcher
    code is auto translated to gui elements, with help text and tooltips as necessary
    user can see more easily what will happen when clicking go, gaining comfort with linux and a bit of familiarity with bash scripting in the process

    What for? They're either interested in gaining comfort with bash scripting (in which case, they'll fucking learn bash scripting - it's not rocket surgery in itself), or just want teh codes and don't care.

    @Buddy said:

    Side Note: @ScholRLEA I think a good idea for any context-sensitive help system would be to support wiki-style editing of the help text and a q&a system from directly in-app.

    A free-for-all editable text requiring an internet connection in a scripting environment? Sure, that can't ever go wrong...

    @Buddy said:

    there is definitely an argument to be made that what you're talking about is actually an argument in favor of graphical programming: you are forced to confront your own spaghetti.

    Except when it's not spaghetti at all. Ever did electrical diagrams (since you mention Xilinx, I guess you did)? Even the simplest ones can get out of hand in terms of visual design, if you're not careful about nicely arranging your building blocks and connections. You basically need to think several steps forward, because one more block can wreak havoc on your diagram anytime - and it doesn't always correspond to the complexity of what it's doing.

    The point is: arranging stuf nicely is hard.

    (by the way: are there any Bash commands that accept more than one input and one output? It seems like every script in your CLI would just be a bigger or smaller line of commands (or perhaps several lines)).



  • @Buddy said:

    an argument in favor of graphical programming: you are forced to confront your own spaghetti.

    No, because the environment caused the spaghetti. Graphically programming as far as I've seen seems to lack in control structures, error handling, commenting/documenting ... causing you to put a lot more effort into it to make something that is acceptable from a coder point of view. Something that will behave not only in normal situations but also covers the edges, something that is not only good for now but is also maintainable and supportable for the next years and the guy who is coming behind. Yes these problems exist with pure text as well but at least there you have more flexibility and power.



  • Sounds like you'd want something a bit like RegexBuddy but for CLI. That representation isn't quite as fancy since it's just a treeview, but it does a good job of explaining the matching steps.

    Also made me think of Kismet in the Unreal Editor. Now that shit gets messy, fast.



  • @LoremIpsum said:

    Also made me think of Kismet in the Unreal Editor. Now that shit gets messy, fast.

    Funny how their examples already show it. Lines going everywhere in an attempt to show the required relations.



  • Thankfully, UE4 simplifies and prettifies things a little... and also provides gridlines.

    Editing image because their stupid wiki insists on forcing the PNG as a download.



  • I also used to use Logicator at school. What made this particular system nice and manageable was that at any point, you could pull some piece of logic off into a separate macro and call it with a macro block.



  • @Buddy said:

    Side Note: @ScholRLEA I think a good idea for any context-sensitive help system would be to support wiki-style editing of the help text and a q&a system from directly in-app.

    Interesting points, especially if the help is shared (or at least propagated, a la a store-and-forward network) across all the systems using it. For the first point, it would have the same potential problems as any wiki - malicious, ignorant or argumentative editors - but the fairly innocuous nature of a help page is far less likely to draw such abuse, and good versioning and a solid editorial policy would solve a lot of misuse problems. However, in this case, commentary notes may prove as use useful if not more so. Perhaps a system in which users can freely add commentary, but would have to submit wiki edits of the core material for review?

    Mind you, for Thelema I plan to use Xanalogical storage anyway, which gives a lot of the advantages of that for free. You'd still want the main text managed by a main group of editors, I think, but commentary would be automatically be available just by the nature of the document storage system (because publishable annotations are possible with any document you have the rights to view in the first place, visible according to the same rules as the original they annotate). Still, when dealing with a conventional file system, a moderated wiki type setup would be a good thing for making sure help information is updated and refined over time.

    A Q&A system would be more challenging, but a fast-reponding expert system with the ability to automatically escalate issues to live support would be a genuine boon. Especially if the answers from the live support were automatically submitted for possible addition to the expert system. Doing it in a context-sensitive manner from within a given application is the tricky part, I think.

    It becomes more of a challenge in my design, though, because you would need hooks into it for developers of tools and layouts to connect their published offerings to - in the Thelema UI, anyone can publish, either in a limited distribution or globally, any document they choose to (with the document itself incorporating any licensing and fee requirements the publisher feels are necessary), and this includes tools (functions, classes, objects, and their public APIs/protocols) and layouts. Making good use of the help and Q&A systems would become a selling point for tool and layout creators, I think, something that would separate the dilettantes from the professionals.

    Mind you, distribution of executables would be in the form of a compressed and encrypted 'slim binary', a partially-compiled combination of the AST and other related information needed to complete and optimally deploy the (cached, not stored) executable images. There would, by the nature of Xanalogical storage, be at least one link between the source code and the distributable, but it would be the creators' prerogative whether to publish that link and under what circumstances. Open source (that is, the document can be both viewed and edited), managed source (open source, but with an editorial policy in place), visible source (it can be viewed, but not directly altered), and closed source would be nothing more than publication options, as would licensing and payments, not just for programs but for any document or link. Keep in mind also that links are not in-band as they are in HTML; it is always possible to add your own links to any document you have rights with, and the links have an existence of their own.

    @blakeyrat asked about how complex file structures would be handled a while back. The answer is, there wouldn't be any; instead of a file structure, your application or tool would create one or more linkage structures that would organize the data as needed. The data would be just the data; the structure is all in how you link it together. Metadata, ranging from font choices to data organization, would mostly be in the links. Links, unlike stored data, are not necessarily permanent; you can have a link that automatically points to incoming data for, say, stock prices. You can have cached data, but most data is permanently stored somewhere on the network. Locally created data is by default stored, while non-local (network) data is by default cached. Executable images are always cached, allowing them to be refreshed periodically so as to re-optimize them as the local system changes. Most of this would be invisible to the user, but it would add considerable flexibility in what they can do - for example, they would always have deep undo/redo, and be able to set version IDs to changes, making a separate revision control system unnecessary.

    These are not, for the most part, my own ideas; I am simply explaining what Ted Nelson had been trying to do for the past fifty years. Now that he has a working system finally, it is becoming relevant that the differences in what he is offering and what is already generally available be understood. I have been following the Xanadu trail since 1989, and while I can see why it took so long to get done (Ted may have many talents, but 'development team management' and 'project funding coordination' are not among them), I am glad he has gotten something working and publish at long last.

    That reminds me, I haven't been in touch with him in a few years. I really ought to email him, just to stay in contact. I only met him in person a few times, but he has an impressive mind and is a joy to speak with, although topic drift is a given.



  • Hearing the name Ted Nelson makes me think of The Incredible Melting Man.

    https://www.youtube.com/watch?v=xWZ5tm5v6Gs

    ROFL what an awesome B movie.

    EDIT: wait, 1989? He's still working on leftover OpenDoc hype!



  • Actually, Xanadu goes back to 1960. He's been at it a looooong time. He coined the term 'hypertext' in 1965, and it took over thirty-three years for even a bastardized version of his ideas (the WWW) to take hold, and his work is still ahead of the curve.

    Admittedly, the core idea goes back even earlier (to the essay 'As We May Think' by Vannevar Bush, in 1945), but it was Ted who first tied the idea to computers and ran with it.



  • @ScholRLEA said:

    and his work is still ahead of the curve.

    Is it really.



  • I would say so, yes. After all, we're still using files, which he demonstrated back in the 1960s was a poor solution to organizing documents, especially ones composed of highly granular data. The hyperlinks in conventional HTML documents are in-band, one-directional, and can only easily refer to documents as a whole (you can point to a section, but you still have to serve up the whole document file), whereas the original idea was to have links out-of-band (not part of the document), bi-directional (you could follow a link back to where it was linking from), and able to reference a slice of the document rather than the whole thing, allowing the user to compose a new document view without changing or copying the original. Xanadu links include not just hyperlinks, but structural links as well, allowing easy creation of multiple views on the same data without having to convert documents from one format to another. Links can be made visible to the user, and manipulated directly, or can be handled by the software invisibly to the user. Because the data is stored permanently and automatically mirrored in multiple places, while still having a single link referring to all the locations it is stored or cached in, linked documents can be served quickly and links never go stale. Storage is peer-to-peer, so there is no differentiation between server and client, and data is always served from the most readily available peer (and can draw from multiple peers, torrent-style). Want me to continue?

    So I would say that yes, this is still beyond what current-day systems allow, both technically and in terms of user experience. It is vastly more difficult to build, and Ted's personal foibles have held it back, but the ideas are sound.



  • @ScholRLEA said:

    After all, we're still using files, which he demonstrated back in the 1960s was a poor solution to organizing documents, especially ones composed of highly granular data.

    Occam's Razor just says he's wrong about that.

    @ScholRLEA said:

    The hyperlinks in conventional HTML documents are in-band, one-directional, and can only easily refer to documents as a whole (you can point to a section, but you still have to serve up the whole document file), whereas the original idea was to have links out-of-band (not part of the document), bi-directional (you could follow a link back to where it was linking from), and able to reference a slice of the document rather than the whole thing, allowing the user to compose a new document view without changing or copying the original.

    This reminds me of the description of the AI that ran Rama in Arthur C. Clarke's Rama series.

    @ScholRLEA said:

    Want me to continue?

    Not really, I checked out during your last mega-post.



  • @blakeyrat said:

    Want me to continue?

    Not really, I checked out during your last mega-post

    I usually think I'm pretty thick-skinned, but guess what? It turns out that flat out dismissal is far more annoying and depressing to me than insults. Congratulations, you've driven me from this forum.


  • Discourse touched me in a no-no place

    Wait, are you really leaving because you've been flat-out dismissed by @blakeyrat ?!



  • Even crazier because I was lying. I read every word of that long-ass boring screed. I regret it, but I read it.



  • @blakeyrat said:

    Even crazier because I was lying. I read every word of that long-ass boring screed.

    Sucker. I totally skipped that stuff.


  • SockDev

    @antiquarian said:

    Wait, are you really leaving because you've been flat-out dismissed by @blakeyrat ?!

    And I thought I was thin-skinned.


  • Discourse touched me in a no-no place

    @LoremIpsum said:

    Thankfully, UE4 simplifies and prettifies things a little... and also provides gridlines.

    That looks great, really pretty, though I worry about what will happen to those links when the link connectivity pattern gets more complex (the example is trivial to handle that way). But wait, what's that in the middle? “Sequence”? Oh boy, this tool is done by a moron; using it for anything large and complicated will fucking suck. I've been doing graphical programming languages for the best part of 20 years, and sequencing like that is really unusual and not in a good way.

    The problem here is that there's basically fuck all to tie the different parts of the sequence to each other unless you start fiddling around with creating contexts that get passed around, which makes the semantics terribly obscure. There's currently a non-local signal from one branch to the next, and that's just catastrophic for a meaningful workflow language; they're not supposed to have that sort of shit as the whole point is to explicitly capture the links between things, the control flow and the data flow. (When done right, it makes the program trivial to parallelise; UE4 appears to go the other way and make everything suck.)


  • Discourse touched me in a no-no place

    @ScholRLEA said:

    A Q&A system would be more challenging, but a fast-reponding expert system with the ability to automatically escalate issues to live support would be a genuine boon. Especially if the answers from the live support were automatically submitted for possible addition to the expert system. Doing it in a context-sensitive manner from within a given application is the tricky part, I think.

    Training up the support goons in India to be useful might be more of a challenge than you expect. It also has huge impacts on the economics of your system, since services (such as live support) have significant costs associated with them. I'm not saying it is impossible, but the implications are profound for how you go about doing things, and might make the project difficult to bring to a successful conclusion, particularly given the nature of the competition.

    “It's Lisp Done Right!” isn't a great raison d'être any more. Not for decades.



  • @dkf said:

    “It's Lisp Done Right!” isn't a great raison d'être any more. Not for decades.

    I think Clojure already is to that point for the real world, more or less.



  • True enough. The Kismet editor (known as Blueprint now?) is made for map makers so they can quickly make simple logic for objects and shaders. Obviously, more taxing tasks should be done by the programmers.


  • Discourse touched me in a no-no place

    @tarunik said:

    I think Clojure already is to that point for the real world, more or less.

    Agree, and I would say OP's efforts would probably be better directed toward improving the Clojure environment.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.