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.
Or like Google Instant Search does now, only in a command line.
In short: slow and annoying for people who know what they're doing. Supposedly useful for people without a clue.
The command line is not coming back, especially with more applications moving to mobile devices where typing is just a hassle.
But whenever we complain about some UI removing menus, desktop launchers and any other easy way of starting an application the fanboys tell us that's OK because we can just type the name of the application on a command line instead.
Let's say I find a web page that I like, and maybe it has a form on it somewhere with a dropdown containing a list of countries. I'd like to scrape that list and do some kind of throwaway mashup for myself. It's painful. Or maybe I'd like to sift through a list of articles on a magazine website, and I care only about some paragraphs which talk about a city I've been to. And I'd like to display those paragraphs on a private dashboard. Again, it's throwaway stuff, I just want it to last for a few hours starting right now.
There are no tools that make this kind of stuff painless. There are not even any *adequate* tools for this. The semantic web *should* make it possible at least. We ought to have ways of extracting the pieces that belong to a web page, not by generic component type (that's what DOM does), but by referring to the content we want in more human friendly ways. We ought to be able to extract the pieces, and recombine them into something else with minimal technical complications. And the result should itself be able to be mined for the information it contains, easily, in case someone else or myself wants to refine/extract some more.
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
There are tools for tagging the content to make it easy to parse - mainly microformats, microdata and RDFa. The problem is that most content producers don't have an incentive to use them.
As an effort from the data consumer end, there's Scraper Wiki, where people can share scrapers, but it's an hack compared to the real solution.
Dilbert RSS feed
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.
Reality check: it never went away.
And I'm not just talking about the fact that power users have continued to prefer it consistently, or even the way Mac power users gravitated towards CLI when OS X introduced it to their world. I'm talking about the stuff my grandparents use. Does that Google search box remind you of anything? Hint: it doesn't involve much clicking on buttons or menus! What about the total redesign of the start menu in Windows 7 to put the emphasis on typing commands rather than dragging the mouse round a menu? Right.
So, children, can we remember what the biggest, most hyped tech story of the last year was? I think it began with an "s". And then there was an "i". Yes, that's right, Siri! You know ... the command-line interface for iPhone?
Seriously, that's what Siri is. So it has more natural syntax than the likes of bash, and it's based on speech rather than characters, but it's still a return to the CLI-type design as opposed to the temporarily-fashionable point-and-click mouse/touch interfaces.
Like it or not, CLI is back, and this time it's for everyone, not just nerds. Guess you're totally wrong! Better luck next time.
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).
I prefer the sexist support of Herman Cain.
His proposed G.R.O.P.E. (General Raciness Of Personal Encroachment) act would have revolutionized America to being a mirror culture of Italy - where proud men would be free to stink and indiscriminately slap womens' butts on the streets, and everybody would like it and laugh over pizza dinners.
I think the fact you must rely upon the site to make the 'correct' choices would be the meat of the complaint. If you are constructing *your* server and client, sure you can apply the discipline and make the correct technology choices. In his example, he is wanting to do some sort automation against arbitrary sites he comes across. Because the technology is so open-ended, he has no idea of how one site will behave versus another and rarely get to reuse code. I've been there a few times, using the web developer features of a browser to kind of reverse engineer how a given web interface is designed and works, with no control and subject to the redesign whims of the server provider, who has no idea or does not care that I'm broken by their new architecture.
There are a few examples of providers with usable interfaces that do care about API compatibility (like Google Maps), but there is a lot more to 'the web' than those and even amongst those you have no consistent API (if Google Maps were to frustrate you or shut down, it's not like you can just change the map data server from google to yahoo and have the same code work without a drastic rework.
XML is like violence. If it doesn't solve the problem, use more.
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.
Or maybe I'd like to sift through a list of articles on a magazine website, and I care only about some paragraphs which talk about a city I've been to. And I'd like to display those paragraphs on a private dashboard.
You're not getting it. Ask yourself this: why would the magazine website want to make it easy for you to do that? If you did, you wouldn't see all the advertisements they plaster on their site to pay for it.
would have revolutionized America to being a mirror culture of Italy - where proud men would be free to stink and indiscriminately slap womens' butts on the streets, and everybody would like it and laugh over pizza dinners.
Ok, maybe I'm missing something basic, but wouldn't these proud men, who like slapping womens' butts on the streets, also get mad if another man slapped their wives' butt while she was walking down the street?
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"
yes it is. If took his example and typed in "Turn Off Monitor" in Windows Vista and up, you will get the GUI he suggests! But of course, the author is still using f**ing XP and lecturing about the future! seriously though, I understand his point. It's more a question of a natural language parsing and guessing by context.
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.
Or like tab completion with modern bash_completions collections.
This is indeed pretty useless. Most attempts to "improve" the CLI with GUI elements have been, other than basic things like paste buffers and scrollbar integratuon. What I'd welcome instead is people approaching GUIs with an eye towards making it so that you don't have to write documentation like "first go to start bar and select control panel and then find the "network and file sharing center" item and double click that and then on the sidebar find "manage wireless networks" and highlight a network and right click and select properties and find Security/Settings/802.1x/blah//blah/blah." Easily documentable GUI schemes could help things a lot.
Someone had to do it.
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.)
Technically, "Linux" doesn't provide any UI at all.
Were you using Gnome, KDE, XFCE, TWM, or some other desktop/window manager?
It's important that we know where to properly assign the blame and file the bug report.
(I'd guess Gnome. They're rather notorious for completely hiding configuration options...)