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 similar functionality to the windows 7 "search" box in the start menu?
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.
mod this off-topic, but i love your climagic twitter feed, even if my CLI of choice is TakeCommand (TCC.exe) and those examples are never represented. But I got cygwin so a lot of it is still useful for a Windows user like me who uses Windows in a "unix-esque way". Thanks for the good work.
-Clio
Karma: Bad (mostly from not giving a fuck)
Blog: http://clintjcl.wordpress.com
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.
Yeah I'd agree with this, made it all the more impressive when I saw this web summarising app on the BBC the other day.
iPhone only, so I haven't been able to play with it.
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
Nice to see more racist support for Ron Paul. I guess Newt and Mitt aren't white enough.
As that is like this and to take it way is a big loss.
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?
it is not useful in the least. he gives an example of turning off a monitor and being able to access it in a few clicks. the problem with that is that the user needs to know that they want or need to turn off the monitor.
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
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.
I'd like to scrape that list and do some kind of throwaway mashup for myself. It's painful.
That's not so much a problem with the semantic web, but simply a lack of a more powerful copy&paste in your webbrowser/OS. The information is already there, nicely structured in a list and all, but your browser provides no way to get it out of the dropdown menu easily. If you go low-tech and use Lynx, you can just copy&paste the thing right out of your terminal with little problem. Nice benefit of everything being text in a terminal, even GUI elements.
Now of course when it comes to building more permanent things, not just throw away copy&paste, RESTful APis are the way to go, as they give you direct access to the raw undelying data, not the pretty-printed HTML gibberish that is split across dozens of pages. What is missing there is again a bit of browser support, as while browsers have no problem retrieving the info, they have no userfriendly way to dealing with a JSON or XML structure in any meaningful way. There is also no standard way of linking that data up into the webpage, i.e. saying "this table/article/whatever can be accessed as JSON (here)". Lack of standard formats for common data, aside from the structure that XML/JSON provide, is of course also an issue.
On top of that however the biggest issue is simply that most webpages don't want to provide semantic information, as that would mean the user would have raw access and couldn't be bothered so easy with adverts and other junk.
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.'.
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.
But if the information is there in my machine/browser I ought to have tools to do what I want with it, irrespective of what the content holders designed for me to see. You seem to argue that what the content holder wants should be good enough for me. It usually is, but only because the effort to extract/repurpose the bits I'm interested in is too high. The current web experience is a bit like looking at a raw log file, without grep. We can find stuff, but only if we look at every irrelevant line as well and concentrate real hard.
Correct me if I'm wrong but the semantic web idea is that publishers (or users) tag bits of a page so that it becomes easy to retrieve the bits by that tag. Ideally the tag should be meaningful, but practically the meanings can't be standardized. Publishers do very little tagging themselves, but users could tag pieces too (for private consumption say) if they have software that makes it painless. The latter is not something that depends on publishers' willingness to cooperate or do work, the latter only requires the community to come up with good tools that work reliably to describe/refer/extract/tag bits of information contained in a web page.
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.
But an API is considerably more effort than just sticking e.g. RDFa tags on your HTML templates describing the content, and more useful for the user than an API that you have to specifically code against, since you can use a generic parser.
Dilbert RSS feed
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?
If we're talking about the Italian model, these "proud men" aren't married - they still live with their mommas, who clean their rooms, do their laundry, and cook their meals for them.
#DeleteChrome
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.
You think those tools should exist? Then write them yourself. There's no economic incentive for others to do it for you, after all.
#DeleteChrome
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.
You seem to argue that what the content holder wants should be good enough for me.
The content holder thinks that what the content holder provides is good enough. That's what OP means (I think).
"I don't know, therefore Aliens" Wafflebox1
it shouldn't be up to them
You do realize that all this requires human effort, and that requires money above and beyond what 99.999% of all web users care about. TANSTAATFL.
"I don't know, therefore Aliens" Wafflebox1
I vote with my wallet, and I'm vocal about it every time a distributor/vendor calls to complain we stopped ordering from them. I then tell them that I have no time to fax an order over, or even to reenter it every time I need 200 line items to replenish production stock/kits. A few distributors allow uploads of CSV or XLS files, and that works reasonably well, even though you still have to screen-scrape the entire process to extract the final outcome (what's in stock, what is the pricing, etc). It gets real boring real quick when you have to manually copy a 200 line PO to your ERP system...
A successful API design takes a mixture of software design and pedagogy.
Found your problem. You seem to think that the web is about the data. Didn't flash give you a hint? Didn't the mac web design pros teach you anything? It's about the layout, stupid!
This post optimized for 640 x480 and best viewed with netscape navigator using adobe type I Garamond font.
help me i've cloned myself and can't remember which one I am
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
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. I
Are you saying you'd like to somehow... combine... other people's data... with other data... generating new data? That's outrageous! And I'm sure it's illegal. Hard-working programmers spent hours of their lives keying in that data, and now you want to just use it as if knowledge were some kind of... shared public resource or something? That must violate about a billionty copyright-patent laws, and if it doesn't, we'll darn sure pass new ones to make sure it does!
Consumers remixing data on their own. What has the Web come to. Well, at least we've made it painful, but we shouldn't rest until we make it impossible!
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
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.
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.)
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
XML and RDF are very different things.
XML and JSON are two serialization formats, yes (although the former supports namespaces, which is useful for serializing certain formats, like RDF).
RDF is a completely different beast: it's a way to describe metadata using triples of Subject, Predicate and Object in a standard way. This format can be serialized in different ways: XML, N-Triples, Turtle, etc.
My point is that using "just JSON" (or just XML) is bad because what happens is that each person invents their own format that the client has to write a data extractor for, while RDF lets you use common RDF triple importers and databases for any source of data.
Dilbert RSS feed
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/bla
I proposed this:
http://brainstorm.ubuntu.com/idea/29001/
While it is supposed to be for phone support, it can also help "expert users":
The user can also type "tab" "B1" "space" to go item "B1".
If this was ever implemented, I'd probably use it to configure/control all sorts of stuff quickly.
http://abstractionphysics.net/pmwiki/index.php#Primary_computer_user_interfaces:
I agree that it's a major problem in using computers nowadays. The first one to publish a solution to this problem will have the next Facetwitoogle. I have my own design for this solution, but have to code it in my free time and will take a while to wire all the needed background processing.
The key to get it right is having an interface simple enough that pipes can be built without thinking, as if the scrapping and piping were part of the browsing itself.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
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