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.
More like 4DOS shell (complete with menu system popping up). Or <Tab> in bash that is probably related to it. Or any autocompletion that relies on a parser instead of a dictionary.
Does Windows 7 search box parse the input to select the context, or use a flat list of "things" to call?
Contrary to the popular belief, there indeed is no God.
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.
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.
JSON is a serialization, not a semantic format. You need RDF or something similar, regardless of its encoding - JSON, XML, Turtle, etc.
And as far as I know, there isn't a standard format for serializing RDF with JSON, although some work has been done on it.
Dilbert RSS feed
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.'.
The overarching issue isn't really CLI vs GUI, but that the OS provides the user with very little semantic information, instead you simply get pretty pixel graphics. Case in point: Look at your screen right now, how much of the text you see can you select and copy as text? The answer will of course vary depending on what you do, but you can be pretty sure that it will be a good bit lower then 100% (i.e. window titles, menus, etc. can't be selected). There is really no good reason for that being that way, other then that being the way it has always been. The text is available to the OS and the applications, but there are no tools to get it out or at least not easily. Now that's of course just a very basic case, the issues goes of course much deeper when it comes to active parts of the GUI. When your filemanager is displaying a list, can you copy it into a spreadsheet? Can you move the play button of your MP3 player over to your iPhone? etc. Some of those use cases are of course a little far fetched, but essentially what you want is a rich and flexible way to interact with your computer. Neither CLIs nor GUIs really provide that and both of them don't really mix well (i.e. double clicking on the output of 'ls' should allow you to open a file).
Web developers don't want you to scrape data. They want you to get the data by manually going to their website with your browser like everyone else. If they wanted you to have a more efficient way of accessing data from their site, they'd publish an API, which is indeed what websites do for things where they want you to automate it. If there's no API, that's because they don't want you to automate anything.
Of course, there's a good reason for this too: if you automate your access to the data, you won't see their advertisements, err, I mean valuable marketing messages.
Exactly. My point is it shouldn't be up to them. I have a computer that can spider the articles like a regular user, including the ads if that's what it takes, and I have processing tools on my machine to mine the content. What I don't have (but *should*, IMHO) are tools that make this pipeline so effortless that I can use them regularly during web surfing.
Genera
Shai Schticks:"You don't make peace with friends, you make peace with enemies"
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.
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.)