Rajesh Jain comments on the ZDNet Linux desktop special report:
Still no mention of Linux on Thin Clients. Linux TCs are disruptive. Everyone today thinks of thick, new desktops. That is because the context is either US, Western Europe or Japan. Change the context to India, China, Brazil and see how the picture changes! It opens up a new world of opportunities and ideas, which is exactly what the tech world needs today.
I made the following comment in response to a post by Karsten Januszewski of Microsoft on the recently formed Aggregators mailing list:
With all due respect to Microsoft and in the spirit of feedback, the recent post suggesting RSS feeds be registered and discovered in UDDI and associated paper puzzles me. Why would I want to discover a simple lightweight syndication mechanism (RSS) through a mechanism that is significantly more complex and heavyweight as UDDI? Otherwise, from a technical perspective and at risk of sounding like a REST advocate, why would I want to discover a"service" that I retrieve with a simple HTTP GET with SOAP API calls? There are a number of mechanisms already deployed that allow one to register and discover feeds in a more lightweight fashion. How does this make the architecture more sustainable when UDDI is a centralized service and that does not have any type of push or pubsub mechanisms built?
I am of the opinion that while it may be "a logical application of UDDI in its mission" it defeats the mission of RSS.
Business 2.0 is the latest to run an article on the use weblogs in corporations as a tool for knowledge management and communication. The moderator of the k-logs mailing list didn't think it was important enough, but I do.
Speaking of which, John Robb writes about his meeting with Rajesh Jain, weblogger and CEO of India's Emergic, here. Rijesh's company is doing work that I find interesting and under appreciated in the land of "desktop mainframes." Rijesh's company is "building a desktop for the 80-90% of people working at corporations in developing countries that don't have PCs." Target price: $200 a desktop. On an aside, I thought Robb's mention of PCs running Linux and Radio kind of amusing since Radio Userland does not run on Linux.
Phil Wainewright summarizes his thoughts on two recently published articles on Web services. On "Web services: Is it CORBA redux?" by Sonic Software's Gordon Van Huizen he writes "The article is a useful primer on why RPC should be avoided -- something I've always felt was the case, without being able to succinctly explain why (until now)." The second is an interview with XML pioneer Dave Hollander entitled "Thinking about the future of data." He writes "It's a helpful introduction to concepts like XML Schema and Namespaces, and why they're important."
Phil also points to a recently published IBM developerWorks article on the topic of BPEL4WS for the curious.
I took the day off yesterday to see Fritz Lang's Metropolis. It was magnificent. This film was released in 1927 before sound in movies and yet in many ways holds up next to other sci-fi movie greats.
Its been re-released after being digitally restored with its original orchestral soundtrack and all its surviving footage. (One quarter is believed lost at this point.)
I saw it at the Ziegfeld Theatre in midtown Manhattan which only ads to the experience. The Ziefeld is one of a near dead breed of movie theatre where it is more about theatre then it is movie. Massive single screen, carved ceilings, crystal chandeliers, brass art deco sconces, and floor to ceiling velvet curtains that drawn as the lights dim. They just don't make them like that any more.
I highly recommend you get to one of the 6 big screens in the States if you can.
[UPDATE: The latest version of this plugin can be found here.]
When MovableType first introduced plugins, Richard Rainwater was one of the first to release a plugin for retrieving RSS feeds and inserting them into MovableType layouts. In recent weeks (months?) Richard's site with the plugin source has been offline and he has been unreachable. Interest in this plugin still persists with occasional requests for it being posted to the Movabletype Plugin Development forum.
I just so happens I downloaded a copy of what I believe was his last public release (RSSFeed v.3) before Richard's site went off line. As I understand the license Richard released it under, I am allowed to "redistribute it freely" under terms that I believe I have adhered to. It is now available here. (If I am mistaken about the license please contact me and I will take it down.)
All is not well though because as Richard indicated in his first post to this thread, the XML::RSS module his plugin uses has "serious problems handling minor problems in RSS files." He had planned to rewrite it with a different parser. To my knowledge that version was never released.
Based on my own experience writing a homegrown RSS feed aggregator with Blagg and examining the XML::RSS feed module, I have a sense of what the problems are. Mark Pilgrim put it most elegantly when he said "You see, most RSS feeds suck." Many RSS feeds break compliance with the sometimes vague RSS specs. Other product (sometimes user) specific tags have been added under the guise of a new specification. Worse many more are not even well-formed XML.
Mark's solution is to use an "ultra liberal parser" to grab information out of RSS files. In order to raise the function and reliability of this plugin, it will need to take a similar route until (if?) feed quality improves. It's something I'm considering doing if there is interest in the MT community.
Kevin Bedell in his O'Reilly weblog post "The Great EJB Refactoring" summarizes the significant "nuggets" from the EJB 2.1 specification:
- Java-based Web Service clients must be able to invoke methods on Stateless Beans using JAX-RPC.
- non-Java-based Web Service clients must be able to invoke methods on Stateless Beans using SOAP 1.1 over HTTP/HTTPS.
- In addition to Home and Remote Interfaces, Session Beans can now also have a "Web Service Endpoint Interface".
So now EJBs=Web Services.
Working in J2ME means do more with less, and has really illuminated specifications in a way I wasn't capable of doing before. The difficulties in the XML spec become much clearer, SVG Tiny starts to look huge, and things which might have looked reasonable in the ever-faster ever-more-bloated environment of PCs become plainly stupid. While I miss a few things (like Java 2 Collections), for the most part, it's a privilege to work in a leaner environment for a while. I doubt this will sweep the computing world, but maybe it should. [Simon St. Laurent - "The strange pleasures of J2ME"]
I know exactly how Simon feels. My research into, and at times outright yearning for, a simple and streamlined desktop apps is a direct result of my work in mobile computing and more particularly J2ME. Working with J2ME really makes you think about what really is necessary in providing the solution as opposed to whiz-bang features and other forms of programmatic kung fu. What's more amazing to me is how incredibly small and lightweight functional applications can be relative to what we have on the desktop. Its made me come to the realization that as programmers we have, perhaps subconsciously, become far too reliant on the every increasing resources the Intel, Microsoft and Dell tell us we need.
This is not to say that Photoshop or a full-featured web browser can be written in a 35k MIDlet. For some applications this approach is not really feasible. Nonetheless most application code are interfaces with some data handling logic. Coupled with Web services to a robust backend, these applications should be quite small and very quick on their "desktop mainframes" most users have on their desktop. If it weren't for the 20 MB download required, I would say the .NET Framework in some ways demonstrates. The MIDP KVM and core libraries are measured in KBs not MBs.
MIDP is a bit too spartan and extreme for use on the desktop. With the basic and limited GUI provided by MIDP, you will not win any design contests. MIDP is just one profile (and the smallest for that matter) in the J2ME world. In the J2ME connected device configuration or CDC (MIDP is in the Connect Device Limited Configuration or CDLC) there are profiles such as the Personal Basis profile, that have richer, yet highly streamlined, APIs that might be more appropriate for desktop application. (J2SE may be fine for developing JBuilder, but its just too fat and overkill for its own good. Don't even get me started on Applets either.)
Simon links to his Tiny API for Markup (TAM) that comes in a 17 KB Java archive file. The kXML 2 parser however is substantially smaller. (~6 KB I believe) kXML a simple pull parser rather then Simon's SAX2-like parser. The next version of MIDP that is in the works, MIDP 2.0, will most likely include an XML parser that I believe may be based on kXML. Additionally the JCP has released or are developing several extension APIs that can be added on an as needed basis -- all in the tens of KB size range.
The uses of XML over expensive slow and unreliable networks is an issue that has not received enough attention in my mind particularly in the area of mobile computing and Web services, a topic I have voiced my reservations about. Jeff Bone has recently been writing about "XML sucking" and in his recent post points to XTalk a "semi-parsed, pseudo-binary representation of an XML" from IBM Labs. WAP employed a similar tact with its WAP Binary XML (WBXML) specification. While attending the Wireless Enterprise Seminar in Atlanta this May, I saw Adam Bosworth present a wireless application framework powered by J2ME using a "binary DOM representation" to communicate to its ultra thin client app. JXTA uses a binary format for its J2ME client, but I'm unsure if it is a tokenized binary representation of XML like the others.
While XML purist probably wince at this ideas, they seem like a reasonable comprise given the constraints of the mobile computing and making XML viable while remaining true to its core principles. I only hope that we settle on one standard method for this encoding.
Recently, the CEO of a well-known software company that's diversifying into mobile applications explained how his developers are having difficulties with the write-once, run-anywhere promise of Java. After writing an application that should supposedly run on any J2ME-based MIDP-compliant (Mobile Information Device Profile) device, his developers discovered that all such devices are not created equal. One device, (Motorola's i85s phone) allowed up to eight characters for labeling the functionality of the device's buttons. A newer device (Motorola's i95cl Color Java phone) only allowed for seven. As a result, the program that worked fine on one device had its button labels truncated on the other. [David Berlind in "Binary compatibility: Holy grail or red herring?"]
Just an FYI for all of you who have not studied with J2ME or just missed it in the fine print-- Sun sanctions, but not encourages, the breaking of write one, run anywhere (WORA) ideal in J2ME. Anyone who has developed for devices know that their feature sets can be vastly different -- even in a single product category like mobile phones. Therefore J2ME is made up of varying device class profiles such as the Mobile Information Device profile (MIDP) for mobile phones and low end PDAs. (Would you want to package Interactive TV APIs in a mobile application?) Sun also allows for OEM specific APIs to be bundled in addition to the standard API in each device class profile such as MIDP. This allows a developer to make choices between compatibility or optimize for the devices capabilities throughout. Device class profiles and OEM APIs are understandable because capturing all of the differing requirements of all devices and make it work in very constrained places would be an exercise in futility.
Its still not binary compatability -- an ideal we strive for, but can never fully achieve. Its also not an "insidious problem" in J2ME, but rather the nature of the device space.
The developers of the nameless company he references used OEM specific APIs by Motorola and suffered the drawbacks of doing so. Shame on them if those developers didn't properly educate their CEO on that point. What is perplexing is that the phones are produced by the same OEM (Motorola) and was poorly designed.
With proper and thoughtful design utilizing a Model-View-Controller (MVC or Model 2) pattern, a certain amount of compatability can be achieved with J2ME code. How much depends on the design and the situation.
I've been involved in a discussion of Flash's capabilities to develop a better HTML editor component for authoring hypertext content through a browser interface. This is a topic I've been openly giving some initial thought to and was consequentially asked to share my views on how this editor might be designed. While far from complete, this post is a summation of those thoughts thus far to begin what I hope is a productive dialog on this topic.
Recently I said that a simple and extensible markup editor is too integral to web applications that it has to be ubiquitous and without constraints. How this editor component is designed can be defined with three primary goals: flexibility, simplicity, and lightweight. Of course these design goals can be interrupted in varying ways and requires elaboration. The also require a certain amount of balance and compromise to achieve a broad set of requirements. Here are some specific thoughts I have had in mind.
FLEXIBILITY
The editor widget should be configurable through a separate XML file (locally or remotely) rather then modifying source code. I really enjoyed using Homesite 2.5 in its day. While it was a code (rather then WYSIWYG) editor, it was streamlined and yet powerful with its easy extensibility. (Has anyone used TopStyle by the same author?) One of favorite features was the ability to create custom editor "tags" by defining attributes such as start and end segments. One click would wrap the highlight text in those start and end tags. This was immensely helpful in pre-CSS days because I could define a tag that was composed of multiple HTML tags. For instance I could create a <scream> tag that would wrap the selected text in <b>, <i> and <font color="red"> HTML tag sets. Besides saving time it made my HTML coding more consistent. Once acquired by Allaire, HomeSite extended this capability by introducing VTML with TagTips and dialogs. Unlike HomeSite these configuration options probably shouldn't be editable directly from the widget rather the site manager or application developer. If one really wanted to allow users to customize the editor they could elsewhere and dynamically generate the configuration file.
This is just one example of why configurability is an important feature. What markup tags are available and how they are implemented (XHTML or HTML?) could also be controlled without code modification. To this point...
SIMPLICITY
The editor should "shield" the user from understanding actual markup and not be limited to producing just HTML. This editor would initially be used for HTML editing interfaces like those found in weblog tools. In considering the bigger picture, I believe it's important to allow for the configuration of task-centric editors. For instance, which is more user friendly: having a bookTitle option or selecting span and choosing class "bookTitle?"
Does not attempt to come close to the sophistication of standalone editors like Dreamweaver and Composer. The value of this editor will diminish if it tries to do too much.
Supports only simple interfaces. The editor should make minimal use of dialog boxes. The widget should only support a single editor window.
LIGHTWEIGHT
Implements "fat" features as web services. Simple helps in creating a lightweight application, but not completely. Functions such as a spell checker or markup validator should offload its processing and data to an external service
I always wish I could read Neuromancer for the first time again, because nothing before or since has given me the rush that it did. [Jon Udell]
How true!
Jon continues with another thoughtful and articulate essay. This one, entitled "Mr. Slippery," on the difficulties of identiity management.
Radio Free Blogistan posted what I believe is a fair and pretty thorough comparison of MovableType and Radio. The commentary has been insightful with users commenting on their experiences, but growing more heated.
One thing I noticed is absent from the comparison was a mention of MovableType's support of the Blogger API. The significance in this comparison is that you can use Radio to update MovableType. Getting this to work initially proved difficult spawning one of the longest support threads on the MovableType support boards to date. Also of note, the Blogger API is somewhat limited and does not support many of the feature of MovableType.
Userland's Jake Savin has been considering an HTML editor in Flash (here and here) and writes:
Why doesn't Macromedia get their heads out of their asses and come up with a really kick ass cross-platform browser-based WYSIWYG editor plugin? It needs to be really fast, do spell checking, send data via HTTP POST, and ideally be extensible using locally running native code.
There's a gigantic opportunity here, and Macromedia has the experience, the marketing power and the developers to make it happen. If their users are already this close, then the engineers inside Macromedia are certainly capable of fulfilling this wish.
This is a topic I went into some depth on back in June. I posted this comment to Jake weblog:
I had written about the illogicz (rich) text editor in my weblog that got the first discussion going sometime ago. Sadly little progress has been made in furthering this idea. Here is what I can offer this thread...
At a meeting with Macromedia I made the same suggestion as Jake -- develop a markup editor widget for the communities use. I was told that Macromedia would leave such an effort to its partners or the flash developer community at large. After several messages to the folks at illogicz I received a broadcast message thanking me for my interest and stating their intent to package the editor into a product that they would offer for sale shortly. I believe some of Macromedia's partners also have plans along these lines.
I don't think this really is going to help if there is a price tag involved. I'm not a flaming Richard Stallman FSF type. I just think that a simple and extensible markup editor is too integral to web applications that it has to be ubiquitous and without constraints.
From what I can tell the Flash developer community doesn't think like we do as coders and backend systems folks. (A real hurdle for Macromedia if they want Flash to be taken seriously as an application platform.) I've been meaning to take a crack at this myself --even going so far as to acquire a copy of Flash MX and draw out a wishlist/spec. However, I've been rather preoccupied and am not much of a Flash developer.
Last, the illogicz editor is indeed read-only. In asking around, I've been told that there is a means for a Flash object to communicate with the embedded pages DOM, but I was given the impression it can be a dicey issue.
Mark Pilgrim: "You see, most RSS feeds suck."
Amen! Mark laments the sad state of most RSS feeds' compliance with specifications and consistency with each other. In response, he's developed an "ultra-liberal RSS parser" in Python that attempts to handle many of the common mistakes so news aggregators and other automated agents don't simply "choke" trying to process large numbers of feeds.
I've been experimenting with ways to streamline my intake of blogs and news using Rael Dornfest's blagg. While I've achieved a certain level of success issues from poorly formed feeds persist.
We can do better and must. RSS feeds are simply too useful to do otherwise.
My recent theme of rethinking the desktop has lead me to the OEone project, a task-centric Linux desktop alternative that utilizes the Mozilla Web browser to offer an intruiging set of features. Also intruiging is its ANYWHERE option that gives users access to their information from multiple OEone machines or any machine with an internet connection and a browser. While it is said to be unlike Windows or OS X interfaces, the screenshots do not convey a revolutionary change. However it does look pretty slick. Sadly it requires a Pentium II or better. Also of note, according to this Newforge article, the team has run focus groups and market surveys in determining its design which is encouraging. Their CEOs comments in reagrds to AOL licensing OEone is interesting if you think about shifting their software into more of an operating enviroment that doesn't necessarily require Windows. Something to watch.
In related news, this CNET article reports Sun and Red Hat are gearing up to push the same old tired Windows-like interface and apps on Linux.
From Scott McNealy's keynote at Linuxworld: "I am a capitalist and am not ashamed of that. One of the ways that we will go make money is selling hardware. I have not seen the open source equivalent of downloading a server over the Internet."
UPDATE: I wanted to revisit this post to note the duel significance behind the quote from Scott NcNealy.
1) Many open source conspiracy theorists seem to forget that Sun (and other companies like them) are capitalist ventures and not academic consortiums or communes of ideological enlightenment. Scott McNealy's comments in a recent interview have been overblown and are more likely to be off-the-cuff unfiltered thinking on his part. One of life's early lessons that I hold dear is that actions speak louder then words. Sun has been one of the most generous commercial technology vendors to the open source community and continues to work with and support that community while balancing its responsibilities to its shareholders -- and its licensees.
2) McNealy's comments continue to reinforce that, as a capitalist, you can make money with open source -- it probably won't be directly though. Sun is a hardware company. Their hope is that the open software brings more value to its customers and drives more hardware sales. Through these hardware sales they will generate revenue (and soon profits once again) that allow them to continue to support the open source community. (Joel Spolsky articulates this point well in his essay "Strategy Letter V".) To this same point hardware and services cannot be open source or free. They have different economics that requires significant up-front and on-going investments in revenue. I believe that increasingly over time, standalone "shrink-wrapped" software companies will get squeezed out of existence, into a small niche or a supporting revenue channel such as hardware or services. Witness Microsoft's battle to discredit open source while eyeing a switch to subscription based services like the sidelined .NET My Services (Hailstorm) initiative.
Jon Udell has moved his weblog to Infoworld's servers here to continue his excellent commentary. Proud papa Dave Winer comments here. (Udell continues with Userland Radio for his weblog. Now if he'd only stop using one of those god-awful default templates Radio ships with.)
Also in other news, last week O'Reilly's Rael Dornfest got his own domain for his weblog now found here.
I happened upon this ZDNet commentary by Patrick Moorhead, VP of Customer Advocacy at AMD, today. I thought it is quite relevent to some of my own commentary of late.
According to IDC's 2001 consumer devices survey report, 41 percent of respondents said they do not own a PC because they have no need for one. This precisely characterizes the third issue causing the technology gap--the inability on the part of the industry to properly convey the values and benefits of new digital products or services.
The industry must realize that the values and relevancies of technologies are different for different people. Educational, cultural and geographic differences among consumers obviously exist. Yet when designing, marketing and supporting a product, the industry seems to take a one-size-fits-all approach.[Partrick Moorhead - Do we really need that new PC?]
What's more interesting it that this comes from a hardware manufacturer. Will this translate into innovative and more consumer friendly computing systems being manufactured? I wish so, but I'm not very optimistic at present.
John Robb shares his thoughts on the potential of personal video recorders like Tivo.
Kevin Werbach replies "...some good observations, but [John] doesn't go far enough. When personal video recorders reach critical mass, they will draw on more raw material than traditional TV programming. Add direct-to-PVR programming, downloadable movies, video of the grandkids, independent programs, and enhanced music content, and you start to get an idea of where things are going."
I agree with Kevin. PVRs should ultimately become the hub for digital media. One angle that John and Kevin don't cover is the potential for these PVRs combined with P2P infrastructure and broadband to drive video-on-demand services. In my brief encounter with the interactive TV space, I recalled that the most difficult and costly part of a video-on-demand system's operation was the backend to serve/broadcast and scale. The infrastructure costs where/are completely out of line with the price consumers would pay. In theory using P2P, video-on-demand providers could distribute the load to the edges and orchestrate the transfer of video from PVR to PVR. I order "Out Man Flint" that is delivered from a neighbor's PVR, while my PVR delivers "Charlie Chan at Treasure Island" that Dave ordered. The provider simply tracks, orchestrates and bills for movies being delivered.
Management of digital content, such as archiving to clear up disk space or storing a movie purchased as a DVD, does need to be adequately addressed to complete the experience. Case in point is the Sony CMT-L7HD that was reviewed in the NY Times recently. This device allows for the storage and their play back of music digitally. However this device lacks network connectivity or the ability to work with your PC or a portable playback device such as the iPod. Jenny Levine writes "...it's short-sighted because no one is really going to buy this paperweight. Why would I when I don't even buy CDs anymore?" Having close to 1000 legal CDs, I concur. (More discussion and insights on the Sony player can be found in this slashdot thread.) The issue of this form of interoperability and holistic management of digital media assets is best summed up Mark Canter in his comment to John's post: "Nobody is going to make a choice between their TV or their PC. They want both and they want them working together."
On a related note for the do-it-yourself hacker types, the New York Times ran a comparison of PC expansion cards for turning your PC into a PVR. Also John Robb points to this link on Tivo modifications via Michael Mussington.
I've also been told small children enjoy using Matchbox on desktop machines, due to the way it simplifies the desktop and integrates well with recent versions of GNOME and KDE. [LinuxDevices.com : Matchbox -- a Small Footprint Window Manager for Embedded Devices]
When I first heard about Matchbox I wonder how it would fair as a simplified desktop interface for both novice users or "outdated" equipment like my laptop. This quote from the article written by its creator Matthew Allum seems to ellude to this same thinking. A very interesting prospect indeed. Has anyone tried this and wants to share their experiences?
A slashdot thread on Matchbox can be found here.
From a link referenced in a recent slashdot thread:
The good news is that the promise of easy, Web services-based interoperation between the two platforms continues to pan out. While there are holes in the technology, I'm confident that XML and Web services will continue to deliver interoperability between "Web connected" but otherwise disparate applications. The World Wide Web is simply growing too quickly and too diversely (with phones, handhelds, on-board navigation systems, entertainment/gaming systems, etc.) for it to be in the financial interests of any vendor to break interoperability.
...
Already, companies are mixing-and-matching Java and .NET solutions to best meet their business needs. .NET is finding a sweet spot for programmed user interfaces, while J2EE continues to enjoy its sweet spot for server-side applications.
[BEA CTO Scott Dietzen in Web Services Journal - .NET & J2EE]
Dietzen offers some reasonable observations of commercial Web services technology adoption in addition to some valid criticisms of .NET. (He is employed by a major Java middleware vendor afterall.)
Nextel announced it has selected a partner to provide its subscribers with inter-carrier text messaging capabilities. This is significant because Nextel was the last US carrier that not agreed to do so. Inter-network messaging ubquitity is cited as one of the reasons text messaging (SMS) has not seen the adoption in the US that other parts of the world have enjoyed.
Mena Trott wrote me to correct a fact on MovableType's usability testing in my previous post. She writes "Though we did conduct usability testing with a professional firm, we didn't *pay* for the testing. They did it because one of the leads was a friend of ours and because they (1) wanted to give us a jumping off point to make the software better because they used the software themselves (2) wanted to help us in a good natured sort of way :)"
Thanks for setting the record straight Mena and kudos to your friend. There is hope for getting the usability community involved. I wish there where more interactions like yours occuring.
"IT managers are increasingly being asked to do more with less, and they're facing a psychology that tells them, 'Hey, you bought a ton of technology 18 months ago. Why not make that work?'" [Infoworld: "Web Services Spending Stalled"]
The over-capacity of the modern CPU has to be made more aware of the user, and the user should find interaction with the machine to be a relationship, not a chore.
After 20 years of speed and capacity improvements, the computer just doesn't seem any brighter or smarter than it used to. And that needs to change. [Thomas Krul in "Generating The Next-Generation Graphical User Interface" via Rajesh Jain via Slashdot]
Krul makes some excellent observations, but does not offer any concrete answers. Linux desktop environments will never really succeed in the mainstream copying Windows. (...which copied Apple which copied Xerox, but that's besides the point.) Instead they should seize the opportunity to so something different and give users a reason to switch that they see and feel in how they interact.
With my recent experiences reviving an archaeic 6 year old Pentium laptop to provide some basic utility, I've been pondering if we don't need to do a complete rethink of our desktops and application design.
Recently I tried out OpenOffice I couldn't help but be a bit disappointed. While I was impressed and commend that community's effort and dedication, OpenOffice (and I assume Sun's commercial version StarOffice) tries to clone Microsoft Office too much. I'm ready to give Office, but not because its free and not because its Microsoft. The fact of the matter is many of the features in Word, Excel and Powerpoint are rarely used by most of us. Their existence only weighs down the application and distract the user. I recall working with WordPerfect 5.1 and Lotus 123 a decade ago and in comparison to MS Office today offers me little additional functional value. These where apps that came on a couple of floppy(!) disks and ran on 386 processors with 4MB of RAM. (My Blackberry wireless PDA has about the same power now.)
Take the word processor for instance. What I want is a simple lightweight version that provides me just the basics. (Back to WordPerfect 5.1 here again.) It would utilize XML document formats and be network-aware to integrating with Internet services. This would be distinct from MS Office. The simplicity and focus of the app would be reason to switch.
It would be interesting to see the result of interaction testing if users where left to compare WordPerfect 5.1 and the latest version of Word and comment on their experiences.
CNET reports: "The World Wide Web Consortium (W3C) on Monday released its first working draft of the Web Services Architecture Usage Scenarios, a document that outlines potential uses for Web services to help guide W3C working groups designing Web services recommendations."
