Slashdot Mirror
The Semantic Line Interface
First time accepted submitter yuriyg_ua writes "[The] semantic line interface may combine features of both command line and graphical interface, which would allow even more complex applications than we have seen before."
The idea is that the layer underlying user interfaces should define the semantic relations between data enabling the UI to provide better contextual information. Kind of a modern version of the CLIM presentation system.
Isn't this like MS Access tried to be back in 2005?
Isn't this similar functionality to the windows 7 "search" box in the start menu?
I remember back in the 90s when I was first learning HTML and there were several articles talking about how the web was not sematic enough and I didn't really get the point. Now I totally get it. While trying to make good examples for climagic on how to interface with the web, its just so much trouble. Even with all the recent focus on good web standards, web developers do stuff that just hinder people who want to scrape data. We really need some good commands for retrieving data from web documents, especially now those that load their data through AJAX style calls.
So a guy submits an link to his own blog page featuring a long and dreary essay containing some half-baked ill-defined vague handwavey idea about some kind of "semantic" interface which seems to have no new basis beyond what google's autocomplete or win7's search functions already do, and it gets posted to the front page? If you're going to allow self-publicity like this, it should at least be for good articles rather than shit ones.
Go back and play Hugo's House of Horrors (or many similiar adventure games of the not-quite-post-text era) and you'll see an interface that looks a lot like what this guy is describing.
There's no -1 for "I don't get it."
Games matter for humans. Games simulate reality, which is unaccessible for us by some reason. Boys (grown-up and not quite) usually play with gadgets. Girls of any age like behavioral games. Touch interface combines features of both. That's why boys and girls are still playing with it. Paradox is touch interface still does not influence PC world.
The first paragraph is riddled with unfounded assumptions and grammatical mistakes - as is, I assume, the remainder of the article. While I stopped reading after the second paragraph, I did spend a few seconds to scroll down to the bottom of the page to the only screenshot of what Semantic Line Interface might look like:
Example of a Semantic Line Interface
Visionary.
The command line is not coming back, especially with more applications moving to mobile devices where typing is just a hassle. The CLI will remain a nerd's tool. That's just reality.
"Sufferin' succotash."
Think all the autocomplete addons for unix shells.
Or even just a bit of work on top of powershell, I don't know if something Something like posh ( http://http//poshconsole.codeplex.com/ ) implements autocompletes like that, but it wouldn't be hard to do in powershell since a well written cmdlet will expose strongly typed inputs which would allow you to use a fancy widget for input without any issues.
As that is like this and to take it way is a big loss.
TermKit?
In the server case, MS is embracing CLI with more and more Powershell instrumentation. In the *nix world we've had it since the inception of the platform, but MS admins are getting very enthusiastic about a CLI now that they are given it.
For the desktop end-user, the traditional CLI may not usually apply, but in many ways all the search dialogs in various places end up serving the role of a CLI,
XML is like violence. If it doesn't solve the problem, use more.
This idea comes up every few years and it always suffers from the same basic problems.. it gets attention because of elegant examples and use cases that the designers come up with, but tends to fall apart when dealing with the flexibility users actually need.. I have yet to see an implementation that handles the command space well. instead they have to restrict it to the point all you end up with is something that is less flexible then both GUIs and CLIs while not really adding anything useful... so it really only ever allows for 'more complex applications' if by 'more complex' you mean 'a few complex use cases are more automated, but don't try to do anything else.'.
Well people are just copying what came before Also there are modern day implementations.
Genera
Shai Schticks:"You don't make peace with friends, you make peace with enemies"
I've proposed something similar for years. Features would have a title and synonyms* and be tracked in a kind of database. One then searches for features similar to using a Google search and the features are then listed in the search results along with parameters, and any links to prerequisites, if needed.
There still may be menus and icons that use (reference) these very same features, but the Google-like approach works better for obscure settings.
* Synonyms may be user-configurable in case I call something different than what Microsoft does.
Table-ized A.I.
It was definitely NOT worth the time to read - and I think doing so may have killed a few brain cells ... my guess is the author re-read their own article LOTS of times.
Sorry that it's behind a paywall, but here is my (peer-reviewed) take on it all http://dl.acm.org/citation.cfm?id=1368052&CFID=76329268&CFTOKEN=39574160
From the abstract:
This research returns to first principals, and considers the underlying Dexter Model of Hypertext, and how that may be placed within a broader model of document content that is amenable to adaptation of content to user needs either through configuration, or through dynamic self-adaptation. The model proposed considers a document in terms of five individual abstractions: content, inventory, semantics, navigation, and adaptation. A simple (fully working) example, taken from a small fragment of Google Maps, is presented to demonstrate how such a model may operate in practice, adapting between two different user profiles on demand.
I dislike GnomeShell.
"Yeah...it was the numbers that were irrational, not the murderous cult of vegetarians...." -- Hippasus of Metapontum
That even though slashdot is the apotheosis of geek sitelization, that this one paragraph hasn't resulted in far dirtier comments about boys and girls enjoying a tactile experience. Is this place just chock full of Sheldon Coopers?
Side note: I don't care if you do or don't like the/any show/character/screen/entertainment media. I just don't care. Don't tell me; I don't care. I put this note in here knowing that some people will have an instant complaint -- guess what...don't care.
"Yeah...it was the numbers that were irrational, not the murderous cult of vegetarians...." -- Hippasus of Metapontum
In the interests of fairness, I am deeply involved with the following website, so my views are obviously bias! Consider the interface at: www.mindports.com Basically, it is used to organize an arbitrary set of categories and sub-categories and sub-sub-categories etc. Each segment contains a brief text label. Once selected, a segment may expose an interface, perform an action etc. After reviewing the article, it occurs to me that we could place commands (or options) through-out a set of these categorical trees. The same command would appear "everywhere" it might reasonably be searched for by folks with different points of view and experience. The interface would allow folks to "find" their command rapidly no matter where it was placed. If we included a text search capability, we would also support die hard CLI lovers. What do you think? Cheers, Bruce.
Bruce A. Knack
Silicon Surfers
The article cited offers a crap solution, but there is a problem. It's the "What menu is that in?" problem. This is a real issue with some programs, especially the ones with modal and/or context sensitive toolbars and menus. It's really annoying when you read the manual, it tells you to use the "join" menu item, you can't find the "join" menu item, and the manual doesn't tell you under what circumstances the "join" menu item will be available.
The original Macintosh Human Interface Guidelines insisted that menu items should be greyed out when inapplicable, but they shouldn't disappear. Many GUIs today either make them disappear, or leave them looking normal but inoperative. The right solution today is probably to grey them out, but bring up a tooltip that explains what's needed to make that function usable.
(My current hatred in user interface design is invisible buttons, ones that only appear when moused over. Facebook is notorious for this. Many users don't know that if you hover over an ad, you get the option to make that advertiser go away.)
Games and 3D Modeling tools have been using semantic based communication between individual components for awhile now. It's very rare that it works without requiring hand tweaks at nearly every step. The only solid way to avoid that so far is just to be very explicit with your semantic declarations, in which case you wind up with a system even more inflexible than what we have now.
I think cuiterm does that.
http://linux.pte.hu/~pipas/CUI/screenshots/scr-4.png
http://linux.pte.hu/~pipas/CUI/screenshots.html
Sadly, when it came out it crashed every now and then and these days it won't even launch.
It's a great concept though
blog.sam.liddicott.com
I have a doubt: if I implemented a SLI application using (for example) the English language, wouldn't it be near to impossible to translate that application in other languages? I'm not an expert in such sectors, just trying to learn! :-)
Android has had this feature - we can specify what is "searchable". that includes "settings". simply search for the setting, click on the item in the drop-down list (search suggestions) and it will take you directly to the setting.
http://abstractionphysics.net/pmwiki/index.php#Primary_computer_user_interfaces:
http://en.wikipedia.org/wiki/DWIM
Quoting the quote:
Although most users think of DWIM as a single identifiable package, it embodies a pervasive philosophy of user interface design: at the user interface level, system facilties should make reasonable interpretations when given unrecognized input. ...the style of interface used throughout Interlisp allows the user to omit various parameters and have these default to reasonable values...
DWIM is an embodiment of the idea that the user is interacting with an agent who attempts to interpret the user's request from contextual information. Since we want the user to feel that he is conversing with the system, he should not be stopped and forced to correct himself or give additional information in situations where the correction or information is obvious.
It sounds like the article is proposing a solution very similar to Humanized's Enso Launcher.
http://humanized.com/enso/launcher/
I tried Enso for a bit. It seems like a nice concept, but one thing that annoyed me to no end was having to type "open" over and over. I want to open something by default.
I think there's still a disconnect between GUI and CLI at a more fundamental level - people think of CLI as meaning text and only text, and GUI as only graphics (despite labels, fields, etc. being textual). Most (or every, if possible) UI item should be interactable (is that a word?) by keyboard or GUI, but for an example I'll start with a command line - when you run a command, it should create one or more interactable objects as the output. In a lot of cases (say, "cp" or "rm"), it could be an exit code that just shows up as a widget next to the prompt on the next line. If you want to know more, you can click on it to get execution details like execution time or whatever - normally stuff you're not interested in, so it stays out of you way. If something went wrong, the object displays an error message, with widgets for diagnostics - anything from a stack trace or signal received to rerunning the command with a debugger attached.
A lot of commands would produce output objects. A "mkdir" like command would create a folder icon you could click on to open, move, rename, etc. "ls" could create an explosion of objects in your terminal window that you can manipulate just like you had clicked on a folder or selected files to view separately.
You might not scroll back through your output so much as flip back to previous window states, like the "Time Machine" interface on Mac OS X. IN each case, you could modify and re-run your command, it would fork into another tree of results. You could navigate these result trees until they expire, like web pages.
As for all the complicated options that some commands have, something like the <tab> key would create a command chooser (all commands matching the first letters you typed) that you could arrow through or click on. Once the command was selected, another <tab> could cause the command to create an option configurator (like the Windows PowerShell does).
And that's just some initial thoughts. Smarter people can probably come up with genuinely good ideas. Sadly, I've seen little of this even tried.
And Jason Foxx likes pears.
"Yeah...it was the numbers that were irrational, not the murderous cult of vegetarians...." -- Hippasus of Metapontum
A moment of person growth, live on Slashdot!
"Yeah...it was the numbers that were irrational, not the murderous cult of vegetarians...." -- Hippasus of Metapontum