today on irc i heard tell of a kde library that someone is hacking on that interfaces with a certain well known social networking site's api. (i'll leave everything rather anonymous to protect the innocent and so as not to steal their thunder should this library see the light of day =) my first thought was "woah, cool; we should build a plasmoid around that!" the library author then said something to the effect that that would be a really cool feature to have: social networking melded with your desktop.
in a related vein, i've been keeping one eye open on red hat's mugshot project. i think it's mostly a solution looking for a problem when it comes to end users, though i agree with the stated problem it is attempting to solve of "open source social networking server software". regardless, it's interesting because they are building a desktop interface to it.
for years and years now i've listened to people proclaiming the end of rich client computing. if you haven't heard, it's been slain with a fell blow at the hands of web applications. this meme predates the turn of the century. the reason this is, in my opinion, complete crap is that it mistakes what the internet is, and web applications are.
they are a means of achieving non-locality of data and function. this is a very compelling idea that has all sorts of amazing ramifications. social networking sites such as myspace and facebook are one of them; youtube is another. informational non-locality allows not only one to access their information anywhere they can connect to the network, it allows other people's information to mix, mingle and synthesize with their own. really cool stuff.
but, and here's the salient point, it isn't a user interface.
web browsers are being pushed and punished to house interfaces and over time these methods and slowly becoming more and more similar to the toolkits and methods we use in rich client computing, only they are more resource intensive, less mature and ... well .. suck. when we drool because some webmail app allows us to drag a mail from one folder to another, we ought to step back and check ourselves.
face it: we're excited about ... drag and drop?!
i won't even go on about how the internet is not ubiquitous now, nor will it be for several more decades at best.
now, i will give the "web 2.0 pwns your children" crowd this much: rich client computing will die a slow and painful death if it doesn't adapt to the new concepts of information non-locality. rich client software needs to be able to extend out beyond the confines of your desktop/laptop/tablet/handheld and into the wider world. more importantly, it needs to be able to meld that reality with the local one.
so .. as i was saying, it would be really cool to have a plasmoid that interacted with that social networking site's api. ;)
Subscribe to:
Post Comments (Atom)
11 comments:
Finally!
Finally somebody that put words to the annoyances I'm experiencing the last 5 years on the internet.
So Aaron, indeed, why are we getting excited about javascript/dhtml drag&drop inside a HTML widget, or a javascript package that builds a rich-text widget on a html page (in supported browsers).
Sure "web 2.0" stuff will enable software makers to bring more mobility and cross-platformness to the world of computers, but at the cost of what? Creating a demand for more standards en browser-support?
If you would ask me web application should, by far, more focus on it's main purpose, providing non-locality and information.
Internet should be a more structured stream of information and data.
At last, I think more and more of the bigger websites should provide XML-RPC interfaces so _proper_, low-consuming applications like Kblogger or Plasmoids can make proper use of the strength of the internet: non-locality!
There are two other reasons why web applications are "more" popular.
1) interfaces are easy to create. While xhtml+css doesn't give you the same control as you would have with qtdesigner, it can be created easily with a variety of editors and regardless of my programming language choice I can still accept input from it in a standard manner.
2) It's cross platform. I use Linux, the guy next to me uses BSD, the designers use their macs and we have a project manager using a wintendo.
Most of the time you can get a site to display the same regardless of browser/platform. If i want an application for our clients to use it has to be viewable on windows, in house it has to be accessable to the designers and the manager and there isn't a hope in hell of getting me to use a non-free desktop (yes it's in my contract).
Can qt do this? a year ago no...now probably , but users "still" have to install applications. That is 1 step too far for many. Esp in corporate environments where they can't have admin access to their local machine.
@andrew mason: i'm talking about mass market developments like facebook, gmail, google office, flickr; you're talking about in-house apps, mostly on a shoestring with time budgets.
i'm certainly not going to purport that web apps have no place in this world. they are very convenient for certain types of things.
but i stand by the concept that they are not a rational replacement for rich client software as a generality, which is the all-too-often assertion made.
i also stand by the concept that rich client software needs to open up more to network services and be easier to integrate with remote service based applications.
they ought to, imho, meld rather than one try and replace the other. i think red hat's "global desktop" concept is actually very close to the mark, at least conceptually (i haven't seen hard implementation concepts).
my prediction (hoo boy, thin ice here i come! ;) is that 10 years from now we'll still use a myriad of little web apps and the client side experience will still center around locally executed applications (where "locally executed" means "not on google's servers"; a thin client therefore isn't the same thing :) but those applications will be far more network aware.
and hey, that's the path kde has been walking down for how many years now?
i also predict that 10 years from now there will be people professing that the rich client desktop will be going away in favour of web apps (or whatever we call them at that point in time) any day now! ;)
you are also correct, imho, that rich client applications are hard to put together. we need to fix that, and it will take more than a VM running some dandy new language to do so.
Yes, yes, yes, yes, yes. Right on the money, Aaron!
I definitely agree with you on the points about the web as a platform who's power is in the non-locality of information, especially interesting since a big focus is to provide apis for everything so that I can easily integrate flickr or facebook into my site, or even into my desktop applications.
On the other hand I don't entirely agree with you about the browser as an interface. I think that a lot of web development is focused on making sites that use the toolkit paradigm (basically widgets) when the browser provides a level of flexibility that is hard to come by easily with a toolkit. The browser is just a canvas/presentation layer on which you can build any number of interfaces. Where in QT or GTK I can make a button widget which looks like the button in my theme, in the browser I can use css to style a div, into which I can put text or images, or I can use the canvas tag to draw something in my little div. I suggest you take a look at an interface like Yahoo! Pipes. While I can conceive how I might do an interface like that using Cairo, I'm confounded by the amount of work It would take compared to the browser platform.
Basically, the problem is seeing the browser as a place to build applications like you would with a toolkit, instead of as a place to build interfaces that are difficult or impossible with a toolkit.
@alexbl: "build any number of interfaces. Where in QT or GTK I can make a button widget which looks like the button in my theme, in the browser I can use css to style a div, into which I can put text or images, or I can use the canvas tag to draw something in my little div. I suggest you take a look at an interface like Yahoo! Pipes. While I can conceive how I might do an interface like that using Cairo"
Qt4 allows you to use that same CSS to customize pretty much any widget at runtime just as you describe with a web browser. you don't need to conceive how to do it with Cairo, you can do it quite easily today with Qt4. pick the right tools and all, right?
now .. while html is presentationally flexible, accomplishing even basic things like decent drag and drop within a web app is impressively difficult. now try and do it between web apps. and that's one of the simplest, most basic things to accomplish with a rich client.
and sadly these remarkably primitive interaction models come at a huge price as far as resources go. html+css+js+aja/rest are not cheap on the resources, esp not compared to a rich client doing the same thing (only.. richer =)
as web toolkits ramp up to be more competent, they will become more complex to use (we're already seeing that happen) until they approach what we have with rich client interfaces in complexity. the win will be more ram and cpu usage to get the level of features we had on the desktop 10 years ago.
"instead of as a place to build interfaces that are difficult or impossible with a toolkit."
how portable is that?
" instead of as a place to build interfaces that are difficult or impossible with a toolkit."
indeed, i'm certain that for the foreseeable future the browser will be the faster, easier route to build certain kinds of interfaces. and in those cases it makes sense to use them. i'm not for the eradication of the browser, but the sensible use of it.
the "best choice" use cases are the minority, though, and if we consciously address the issues in rich client computing, they will becoming even fewer over time.
the issues are, imo: simplicity of implementation language; portability between platforms; easy network delivery; simple customization of look and feel; good integration with service based offerings.
i hope in the future we won't have to choose between the current strengths of web browser based interfaces and rich client software.
``Qt4 allows you to use that same CSS to customize pretty much any widget at runtime just as you describe with a web browser. you don't need to conceive how to do it with Cairo, you can do it quite easily today with Qt4. pick the right tools and all, right?''
I'm not suggesting the use of CSS to style a button widget, I'm suggesting the creation of your own button which you style with CSS. The advantage here is that there in QT you get a button that looks and behaves a certain way, in a browser you have a very easy method for building your own interface components that steps beyond the parameters set by the button widget.
``as web toolkits ramp up to be more competent, they will become more complex to use (we're already seeing that happen) until they approach what we have with rich client interfaces in complexity. the win will be more ram and cpu usage to get the level of features we had on the desktop 10 years ago.''
I think you're missing the big point I'm trying to make which is that the a toolkit is a static set of widgets (with some room for canvases and custom widgets that depending on the toolkit range from aggravating to damn near impossible to implement) whereas the browser platform opens up a space for experimenting with UI ideas that go beyond trying to mimic ``rich client applications.'' I think the problem is that web UI development is focused on being like desktop applications instead of trying to take advantage of the flexibility provided by the browser platform.
I also won't pretend that the platform isn't very resource intensive particularly when you consider the amount of round trip network traffic that happens with a very interactive or constantly updating application, but I think that developers are starting to find the ``sweet spot'' for how to best implement applications like this and that good patterns will emerge for the web as a platform that will make for much better resource usage. Again I think some of the problems are in part that a toolkit style approach is being taken. Something like a signal in QT is a fairly cheap operation when an applications logic is all in the same place, but when you separate the logic between browser and server signaling changes becomes a fair bit more hairy. Instead it's time to look at things like buffering changes and only sending them in blocks and other ideas that could potentially reduce network traffic and time spent executing XHRs.
``indeed, i'm certain that for the foreseeable future the browser will be the faster, easier route to build certain kinds of interfaces. and in those cases it makes sense to use them. i'm not for the eradication of the browser, but the sensible use of it.''
I'm not suggesting that the browser is a replacement for all applications (I personally do almost everything with non-interactive command line tools preferring them over curses, gtk, qt, and web interfaces) or even any applications. I just think that the browser provides a lot of space for innovation that isn't as easy (and often times not even possible) in the regimented toolkit space. UI interfaces seem painfully similar to the very earliest interfaces and the flexibility of the browser provides a place where it's possible to break free from this because the foundation isn't all built for you already. Sadly the direction of development seems to be going towards repeating the same mistakes and providing the same sort of interface paradigms.
@alexbl:
"I'm suggesting the creation of your own button which you style with CSS. The advantage here is that there in QT you get a button that looks and behaves a certain way, in a browser you have a very easy method for building your own interface components that steps beyond the parameters set by the button widget."
which interface components do you see coming out of the browser that steps beyond the button widget (to keep going with this example =). i'd really like to know so that we can offer the same kinds of things on the desktop.
i suspect we already are going there with kde4, but i'd like to hear more about your perspective and experience on it, as you evidently have thought about it quite a bit.
"that the a toolkit is a static set of widgets"
that has been changing over the last several years. while this may be true of many toolkits, it's certainly not an absolute attribute of toolkits and Qt4 does a lot of interesting things to move away from this.
" (with some room for canvases and custom widgets that depending on the toolkit range from aggravating to damn near impossible to implement)"
i know what you mean. it's one reason i love working with Qt.
"whereas the browser platform opens up a space for experimenting with UI ideas that go beyond trying to mimic ``rich client applications.'' "
i think the same can be said about many of the new concepts hitting progressive toolkits, like Qt/KDE. QStyle, QGraphicsView, SVG, QCA .. these are opening some exciting doors.
i really think we can do much better than the browser with these tools; but of course we need to know what that means. do you have examples of the kind of UI ideas you mention here?
"I think the problem is that web UI development is focused on being like desktop applications instead of trying to take advantage of the flexibility provided by the browser platform."
i certainly agree with that. additionally, i'm not sure how much the relative flexibility in the browser platform is inherent to it and not just a result of rich client efforts not addressing those issues clearly.
iow, the browser is being (mis)used in large part because traditional toolkits stopped innovating sufficiently.
again, not to toot our horn too much, but i think Qt is a progressive leader in this regard.
Programming Qt is really easier than this HTML/CSS/JavaScript/PHP mixture you have to do when programming AJAX - or however you call it.
BUT: the big bonus for web-apps is the deployment! just send someone the login and you are done...
(you don't have to care what os he uses, explain him how to install the application)
Furthermore the whole process of updating is so much simpler.
niko
I must admit that finding people doing innovative interface design anywhere is hard. The example of an innovative browser interface off the top of my head is Yahoo! Pipes.
Great discussion.
What everyone is desperately trying to do with the internet is to make it two way. Really two way, not click on link, feed data, display it, click on another link, feed data, display it.
The desktop toolkits allow for a much greater interactive experience. The problem is the lack of data.
Youtube, or google, or most of the web apps are simply interfaces to vast data repositories, with innovative ways of presenting the data to the user. The interfaces are not particularly interesting, the data is.
Model-View can tie this all together. My experience with Qt4 was moments of wow followed by long stretches trying to get it all to work. Very powerful but a little tricky. This isn't a criticism, more an acknowledgment of the work that needs to be done.
Of course the only interface into the desired data (with rare exceptions) is through a browser. Google earth Qt edition uses both.
What I would like to see is all the KDE4 data repositories exposed as models. That way applications could use whatever makes sense without having to duplicate data stores. In a sense KDE4 acting as an aggregator.
Derek
Post a Comment