Recently in Microcontent Apps Category

Reporting from InfoWorld CTO Forum, Jon Udell summarizes Adam Bosworth's keynote address where he paints the big picture on Internet application architecture.

As I have mentioned previously, I thoroughly enjoy hearing what Adam has to say. (I still maintain that the world would be a much better place if he had a weblog.) Again he does not disappoint, making several insightful observations with his uncanny clarity that are spot on. Topics covered included coarse-grained messaging, XML repositories, XQuery, message-driven model, asynchrony, and public contracts.

It was his reported comments on scripting rings most true for me presently. Insights from Bosworth, Udell and Ward Cunningham have reinforced and contributed to my thinking in how Sun should (but probably won't) simplify Java development and why Flash/SWF is on track to achieve a great deal of success in developing Internet applications.

Bosworth was instrumental in driving the effort to add native XML scripting to ECMAScript that was just officially announced this Friday. Being BEA's Vice President of Engineering, it is no surprise that BEA is the first to implement it in a product.

Certainly the combination of some of the browser interface technologies (specifically XUL and in the future XForms ) could develop into a strong candidate platform for Internet applications, but quite has to develop soon if it is to happen at all.

UPDATE: Chief Software Architect, Kevin Lynch notes Adam's keynote and comments on scripting by comparing it to Macromedia grand plan. He final concludes with a familar reconmendation – Adam, you need a weblog! Makes me actually feel like Kevin might be out there reading my weblog.

If Adam wants a weblog, I'll personally volunteer to setup MovableType for him. He probably doesn't want me to do any design for him though. ;)

Macromedia announced Flash's independence from the browser and an associated marketplace for Flash applications called Central. This is a very positive setup towards Flash's adoption as a microcontent client development platform and application-centric mate for the browser. The issue of a Flash application development tool for programmers is still left unresolved. I wish for a Flash application compiler. More on my O'Reilly weblog.

UPDATE: Seems my wish could be coming true sooner then I thought. Macromedia's Mike Chambers writes on the tantilizing Royale project that was shown a the FlashForward conference today.

I just got around to reading Dave Winer's "First Essay of the Year." If you know Dave and can parse out his self-serving comments, he has some very good thoughts. For instance The Web uniquely wants to be used by everyone, not just for the purposes of big companies and their profits and paranoia. This is a foundation that I think we agree on.

Agreed. I wouldn't just differentiate on big companies though.

I thought Jeremy Allaire's commentary on the essay more relavent and better stated. Allaire writes The question it really provoked for me, and one that has been lurking in my mind for the past few months, is whether weblogging as we know it will truly become a mainstream form of personal communications and sharing, rather than it's current perceived niche as form of personal or independent Internet journalism.

Jeremy lists his personal perspective as to why weblogging is revolutionary -- publishing to the web is simple and your content is well structured and shareable. In order to gain mainstream acceptance he asserts weblogging, as it is known today, will need to Break out of the calendar journal or narrative metaphor and Embrace richer forms of expression through graphics, audio and video.

It would appear that 2003 is shaping will be the year of the two-way web and, as I like to think about it, the universal canvas.

The ever-insightful Jeremy Allaire offers his views on "holistic Web services."

...I've continued to be annoyed by the narrow-minded thinking that has dominated discussions of web services to date. Like many IT technologies, the central thrust of the web services worldview has emerged from the classic middleware infrastructure providers, which has in turn colored our thinking on web services significantly. The essential problem is that web services as defined by a core collection of XML protocols (SOAP, WSDL, UDDI) focuses almost entirely on API-level application integration, rather than a broader view of how software will be created, distributed and consumed in the future.

Jeremy goes on to discuss the relationship between Web services and Application Service Providers (ASPs) in addition to "the missing pieces" in ASPs vision.

He concludes, "let's turn the debate around and focus again on the broader vision of software as service rather then keep ourselves down in the plumbing....."

Amen. This is the exact notion I had in mind when I wrote "Flash MX and the Bigger Picture: Lightweight Internet Applications".

[UPDATE: Just catching up on my reading I found that Jeremy also has posted an equally as insightful piece on "The Problem of Scale" that is also worth a read.]

Jon Udell notes Macromedia CTO Jeremy Allaire has created a weblog and starts off with a post on "rich-text" editors developed in Flash MX. Like Jon, this is a topic that has been of great interest to myself in the past. Jeremy links to a review by Flash VooDoo of three of these editors. They show a lot of potential though none of them are exactly what I want.

My first article for the O'Reilly Network, "Flash MX and the Bigger Picture: Lightweight Internet Applications" was published today. Its the expansion and refinement of my past thinking here and elsewhere.

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.

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'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

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.

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.

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.

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.

On my recent family vacation, my experiment in trying to revive an ancient laptop proved fruitful to a degree and enlightening.

I was able to login, get mail, do a post to the blog, and run some perl scripts I use. I didn't try any extensive writing this outing, but Word 97 seems to be doing fine. The speed in which Windows 95 boots up, even on a lowly Pentium, highlights how fat later versions have become. (Can you imagine how fast Windows 95 would boot on the machines we use now? Has anyone tried this out of curiosity?) Using Windows 95 also highlights how cluttered and complex Windows has become. Granted Windows 2000 on is a true 32 bit OS and I have not had the chance to try out XP, but I have to wonder is all of this heft necessary? To that point, I was quite surprised at how memory intensive, and thus sluggish, Mozilla was. I had expected more since the browser is often touted as the client for lightweight application architectures. I also found what seems to be a bug. Trying to save anything to the file system through the browser -- HTML pages, bookmarks or file downloads -- crashes Mozilla. Also 256 colors seem to not be a concern any longer. Is there a 256 color safe skin for Mozilla? Also of note, I missed the high resolution of my desktop (1600 x1200) and some of the interface refinements in versions that came after Windows 95. I also missed not being able to have my music on my laptop. This has more to do with the 800MB HD and not having a network card or CD-ROM either.

Overall I’m not getting as much as much utility as I had originally hoped, but certainly a fair amount out of a machine that most would considered garbage. At the same time I'm frustrated and disheartened by the general lack of optimization in PC desktop software today that this experiment has illustrated to me. It makes we wish Linux on the desktop was more refined and easier to install. Maybe I should try out OS X. I could audition to do a "switch" commercial for Apple.

Intel missed its numbers this quarter on poor sales. AMD and Transmeta continue to struggle also. Dell is expanding beyond PCs, Gateway is still fighting to be profitable again, and others have failed completely. Entry level brand name machines can be had for just over $500. (See "Computers: Why the party's over".) Microsoft reports a slowdown in the frequency of software upgrades and is tightening the monopoly thumbscrews to get users to upgrade and new licensing plan that will maintain is astronomical revenue stream and cash supply despite the slump. the rest of the software industry isn't as fortunate these days.

It makes me consider have we reached the practical limits for general desktop usage? Do we really need Pentium 4's or have desktop CPUs become "fast enough" for most of us? Have software designers fallen into a because-it-was-there syndrome that current hardware presents? Does Windows need all of these features, options and overhead or are these features an attempt to justify upgrades and new computer sales? What if Microsoft made simple, lightweight and ease-of-use the highest priorities in its product designs? Would their products like Windows and Office still look the same? And more importantly, would customers like me be more happy and willing to spend more and more frequently?

In "Colin Moock on Flash MX" Richard Koman interviews the author of O'Reilly's ActionScript: The Definitive Guide. Moock really nails what I've been talking about with Flash -- its more then just a vector graphics and multimedia platform, but rather a means of developing and deploying lightweight cross-platform Internet applications.

I am convinced that the emerging service-oriented Internet will necessitate such a platform to compliment the document-oriented web browser. Moock agrees: "Flash is a loud message to everyone who is working on standards: this is obviously a need, so maybe it's time to pay attention to this kind of content."

This is encouraging to see, but we're a long way off from this notion gaining the support it needs to thrive.

Mozilla could be developed into an application virtual machine[1] for delivering lightweight easily scripted applications over the Internet. Last week's release of the Mozilla browser got me thinking about the possibilities. Recently I've been exploring Flash's ability in such a role because it is more then a vector graphics and multimedia tool and its the most mature and widely deployed engine that could fit the job. It is worth considering how to leverage the Mozilla communities work to support such a platform.

David Boswell in his article "Mozilla as an Application Virtual Machine" over 2 years ago raised the notion of Mozilla potential. At the time Boswell focused on Mozilla's strong cross-platform code base as the means for such a function. To some degree he is correct. XUL allows developers knowledgeable in XML and Javascript to modify and enhance the Mozilla browsers function. However the development of non-browser applications is limited to knowledgeable C++ programmers willing to learn the internals of the Mozilla project's work first. While the project's work is yielding these types of applications, it either excludes or burden most others from participating and benefiting to a larger extent. This is fine for some, but is unacceptable overall.

The Web browser has and will continue to serve us well. Mozilla is the best browser yet. My experience using it full-time since release candidate 1 has been nothing short of superb.

As the Internet continues to evolve into an "Internet operating system" of programmable interfaces, ubiquitous access and distributed computing resources, the document-centric browser is an awkward solution to a growing number of emerging needs. The browser is not dying by any means -- it just needs a mate to compliment it.

This compliment would support an open cross-platform means of easily developing, deploying and running applications. Ideally it would make use of the same standards and technology utilized by web browsers. These web applications would be easily "streamed" over the Internet and executed locally rather then on a server. As a former Visual Basic guru from back in the early 90's, I envision this Internet application virtual machine to do for Internet applications what the Visual Basic runtime engine did for Windows application development. I initially referred to this as an "application-centric browser" because this platform shares many of the same properties and core technologies and fuses them with an application framework engine.

Here is a cursory look at what core elements that are already available through the Mozilla project that could be utilized in developing such a platform:

• The ability to script logic with Javascript.
• Graphical display using HTML and CSS.
• Data handling through its support of XML, XSLT and DOM.
• User interface design through XUL.
• Basic Web services support via SOAP and XML-RPC. (Perhaps more is needed though.)
• Vector graphics support using SVG. (Native support is coming.)
• A component API for creating plug-ins when necessary.
• Packaging capabilities using JAR (however this function is currently limited to the browser skins and would require some adaption)
• Network installation capabilities using XPI archives.

This is a strong base for developing an Internet application virtual machine, but more is still needed:

• Better forms support. Existing HTML forms support comes up short requiring XForms support.
• A lightweight web application server for supporting peering, messaging and the dynamic generation of local displays. (Userland's Radio is a prime example. KnowNow's technology is also worth noting here.) Some of the functionality already exists to a degree, but could probably use additional refinement and functionality.
• An application manager to handle environment functions such as streaming, upgrades, uninstallation, managing tasks and security.
• A security sandbox to prevent buggy or malicious applications from doing damage to the local system. Mixing easily downloaded applications and given them access (however limited it may be) while risky, is necessary in order to be useful.

In some respects the open sourced SashXB for Linux and its closed source Sash for Windows is quite close in many respects. (Incidentally some of Mozilla's code is used in SashXB.) SashXB is not nearly as cross platform and lacks some of the above feature list such as a built in web application server. I won't be able to go into a full comparison here.

Mozilla has most of what it takes to be the foundation to an Internet application virtual machine, but some additional work and assembly is required. The extensive open code base and its adherence to standards makes it an ideal candidate to create an application-centric compliment to its browser. In order to move forward the need for such a platform must receive wider recognition in the Mozilla community and a focused concerted effort initiated.

--

[1] In recent writings I've referred to this concept as an "application-centric browser" for lack of a better term, but given Mozilla is a Web browser I'm refraining from using the term to avoid being too confusing. I still am in search of the "perfect" term for what I am thinking.

It been documented that using your browser as a writing tool has its limitations and is painfully lacking in some respects. Jon Udell has covered this better then any one else in his article on the universal canvas. Jon sums the issues up nicely in his review of Radio 8:

Part of the answer is a ubiquitous replacement for the browser's hopelessly primitive TEXTAREA widget. The Microsoft DHTML edit control, exploited by Radio and other web-writing systems, is a flawed solution in several ways — IE-only, producing HTML rather than XHTML or XML. But the fact is that for the 90 percent of users who are running IE browsers, it works well enough — and (to my taste) better than the Java-based alternatives I've tried.

I've been painfully aware of this myself as a developer of several content-oriented sites. I'm also reminded of this shortcoming as I write this post in Notepad because I find the TEXTAREA interface of MovableType too difficult. (There are desktop applications such as w.bloggar or even Radio that make this easier, but I'm a fairly transient person I often find myself at a machine that is not my own.) Like Udell this has lead me to be on the lookout for a better solution.

This search has lead me to consider the possibility of using Flash. Flash 4 added forms support. Flash 5 added XML support. With MX, the latest version of Flash, Macromedia has added interface components and more robust scripting. With these new features and its widespread deployment across multiple OSes and browsers, I theorized that a replacement component may be possible. Just I recently came across Stuart Schoneveld's promising Rich Text Editor that seems to validate my theory. There is no source or documentation to know to what extent the control could be pushed but I find this encouraging based on my cursory knowledge of Flash.

This find has lead me to consider the possibilities of having an extensible editor component that, I think, could potentially bring in-browser authoring to a new level. With the use of an XML configuration file an application developer could create a in-page editor that are specific to the writing task and obscures the user having to understand the semantics of the underlying markup. A user would not have to be bothered in knowing that a title string should be centered, bold and blue or encapsulated in a <span class="title"></span>. They would just have to select the string and select title from the editor's tool bar. The editor would handle the translation. That would be very helpful.

CNET reports that Macromedia announced a partnership with Web usability expert Jakob Nielsen to develop guidelines for developing Flash-based applications.

Nielson has been a harsh critic of Flash and rightfully so. Back in March when Flash MX was released I wrote "Unfortunately most graphic designers I know seem to lack the common sense to save their artistic ambitions for the gallery and not my screen when I'm trying to get something useful done. I wish there were a standard to do something about that." I'm pleased to read that in some sense it will.

When Macromedia released this latest version of Flash, they raised the ire of standards and open source advocates alike for suggesting that web sites be designed entirely in Flash and not supporting related open standards such as SVG and SMIL. I weighed in that there is a growing need for a "standard" lightweight environment for developing and delivering applications and that Flash MX attempts to address it. Whether Flash is the best or right solution to addressing this need is open to conjecture.

The Web browser serves its purposes as a very useful and vital tool to making the Internet work, but it's an awkward way to deliver true application functionality. In mobile computing where function is valued over content, we've already seen the general failure of browser-based solutions (WAP) and rising interest in J2ME applications. This is why I'm convinced that an application-centric "browser" is needed to best utilize the emergence of the programmable Internet via Web services and advance the function of the Web as we know it.