apk zipalign

I've been reminded, in some excellent email exchanges, that there is no real site for Zope 3. There is dev.zope.org/Zope3 - the Zope 3 development Wiki, but not much else. I think that it may be due, in part, to the fact that Zope X3.0.0 had the 'X' in the name and wasn't quite taken seriously as a final release? I don't know. But now that Zope 3.1.0 is released and the 'X' (which previously stood for experimental) has been dropped - Zope 3 has truly arrived. However, although there are at least two books available covering Zope 3 development and usage, there isn't much in the way of informative and "quick start" web sites right now. Having not the time to make one myself, nor wishing to request someone else whose time is also limited to do so, I want to just point to a couple of Zope 3 Quick Starts that are showing up.

Benji York's Quick Start

Benji York has started compiling this quick start. It is not based on Zope 3.1, but rather on a pre-release version of Zope 3.2 (due this winter) from Subversion with instructions to check out. Personally, I prefer using release versions which use a more familiar "configure; make; make install" process. But setting up aside, Benji's document is helpful and comprehensive and also showcases some Zope 3.2 features such as zope.formlib.

My personal complaint - or just a note - about Benji's piece is that he takes the world's stupidest example application, Hello World!, and shows a verbose Zope 3 solution for a situation that is quite simple. So people may look at it and go "It takes all of that to do "Hello World!?!?" when that is not the point. The point is showing the various aspects of Zope 3 development - using zope.schema, persistence, and configuration via ZCML.

Zope 3 in 30 Minutes

This one showcases a bookmark application which runs and works in the default Zope skin (but should work in most skins that build on the default layer). Um, don't worry about skins. What's important here is that this is an application with containers and objects and testing. In its current version, the author is short on explanatory text, but it is full of working code. There is a fair amount of ZCML to look at, but what sort of domain specific languages could or should be used for configuration is another debate.

Both of the above are young drafts, but they do provide a couple of decent places for getting started without a book.

Some other resources:

Simple Todo

The Simple Todo Application is a series of posts that I wrote on Industrie Toulouse which has now been properly archived. The series went up to a usable point, but still could have gone farther. I also don't have some screen captures properly re-linked yet and am unsure when I might get around to that. But still! There it is. And I know that this content should be reworked and re-released online soon by another party.

World Cookery

The site supporting Philipp von Weitershausen's book, Web Component Development with Zope 3. The site is likely to expand soon with more useful information. But along with supporting the book, it contains downloads of source code from the book, and also of the code that runs the site.

Z3 Base

A collection of Zope 3 related software. There is a great trove in the subversion archives. This is where Five came from. Five allows Zope 3 software to be used in Zope 2. It also houses sqlos which is a SQLObject Support package for Zope 3, which allows SQLObject objects to fit into the greater Zope 3 application architecture. I don't know how well that's been maintained, but it is definitely an interesting project to look at.

Z3ECM - Content Management for Zope 3

This site has blogs, documentation, proposals, movies, prototypes, and more, for building a high class content management platform on top of the Zope 3 framework. There is a lot of information and ideas floating around here, and the animations are very impressive.

At long last, I have finally gotten around to archiving my old weblog, Industrie Toulouse. It is moved to euc.cx/toulouse, aka Toulouse Archives. This houses my blogging activity from 2002 to early 2005. Not all images may work, and there is no search, but all other links seem to work fine.

Griddle Noise will continue to be the home for new posts and surliness for the time being.

Sincerely,

A post came to my attention today covering "Best of breed controllers for MVC Web Frameworks." It covers, again, toolkits like Ruby On Rails, Django, CherryPy, and so on. The author initially treated this as a recent phenomenon of the last few years, but he was quickly corrected by Philip Eby in the first comment.

Publishing objects on a nice URL is nothing new, and one of the best toolkits to do this sprang up in 1996 - Bobo, aka, The Python Object Publisher. In the comments, some of the legends and myths are covered and dispelled concerning Bobo's origins. My former boss and all-around-great-guy Paul Everitt mentions in the comments (and on his on weblog):

I remember thinking last year, after all this time, most packages haven’t caught up to what Jim had on his laptop after the plane ride back. So many systems seem more like the “Gateway” in CGI, than systems that adopt the object model of the web.

A few days ago I started writing a post on my own about my experiences with this back in the mid-nineties. Now that the history of Bobo has been covered elsewhere, I can just tell of my experiences with it prior to my joining Digital Creations in mid 1997.

The problem of "numerous web frameworks" is nothing new for Python. In 1996 I had crafted my own, taking some (very light) inspiration from the great WebObjects. I was aware of this tool "Bobo" but I didn't quite grasp its significance at the time. When I published the first version of my tool, netstijl, to the Python web-sig, Paul responded with a "yeah, we've done that too" reply.

A few months later, at a rarely-paying job high on the east benches of Salt Lake City, I was growing frustrated with an application I was working on. My responsibility was writing a socket server that queried closed-caption text feed archives from television, and returning responses to a Java Applet Client which would show the results and also pull down still images associated with those results. This was before server side Java, RMI, etc. My part of the code was written in Python, and was a good model-controller separation. But the Java client development was coming along atrociously slow. So sometime in early spring, 1997, I decided one day that I was going to turn my work into a web application and not care about the applet.

I turned to Bobo for my work. By the end of the day, the conversion was done. I worked on a new set of controllers for a few hours in the morning, had lunch, and spent the rest of the day making the HTML look pretty.

One Day was all that took.

Over the next couple of weeks, new features were added. The biggest of these was the "advanced search" which used HTML Frames and "multipart/x-mixed-replace" to push data to the client, such as the images that were shown next to the search results. All of this on my model from the socket server implementation, but now published via Bobo and my controllers and templates. In short time, I had done what we were having trouble accomplishing with the Java Applet, but now using just HTML, Bobo and Python 1.3 and 1.4.

Ever since that spring, I have been using that same basic toolkit. In September 1997 I joined Digital Creations as 'Principia 1.0' was being developed, and worked applications built on Principia and Zope (which was the open source Principia) there for the next four years before coming back to Utah to be poor (wink) as both on my own and with a couple of different companies I've continued to develop and deploy Zope based applications. I've done just about every different kind of Zope development imaginable. DTML Scripting, ZClasses (Briefly), ZPatterns (a Philip Eby invention), CMF, scripts and templates over RDBMS based data (often still published along a readable URL!), 'Product based', building our own frameworks over Zope, and through gateways to our own data management frameworks that had little knowledge of Zope but could communicate through a new model layer and take advantage of Zope for managing not only views and web publishing, but for managing transactions.

Other things that made Bobo cool were some of the little features that you didn't necessarily need, but were useful when you did - security and transactions. Security has always been a feature of Bobo, Principia, and Zope. Bobo also came with a transaction manager that - to this day - starts a transaction at the beginning of a request and commits if the response is successful and aborts if there's an error. With it, I never had to worry about half-written data (so long as I was using a persistent database manager), or data being written in one database and not the other... Unless of course that database was pre-InnoDB MySQL or an LDAP directory (and I even made a couple of valiant efforts to do transactional LDAP writing, at least within Zope. They never quite worked properly though).

I remember coming across this feature in 1997, before I joined Digital Creations, and how happy it made me. Web development was still very tough at the time, and I still bore many scars from CGI programming where I'd often have half-written data before an exception happened and I didn't get a full file made. When I started using BoboPOS, the persistence system that became the ZODB (Zope Object Database), such problems magically disappeared!

Bobo was even doing REST-ish communications back in the day. There was a 'bobo Client' library which basically allowed for RPC / Corba-ish communication, but using HTTP as the backbone. Again, this was long before XML, XML-RPC, SOAP, webMethods, ICE, and so on. I used it many times to script batch updates that I needed to make to an application server. I don't have any code in front of me, but basically it looked like this:

john = boboclient.Object('http://www.example.com/people/johndoe')
john.setJobTitle(jobtitle='Vice President, Software Engineering')

On the 'Object(...)' call, you could set up authentication parameters, what HTTP method to use, etc. And basically all that the bobo client stuff would do is turn the method call, 'setJobTitle' into a GET or POST to the url with the method name attached. As a GET, it would look like this:

http://www.example.com/people/johndoe/setJobTitle?jobtitle=Vice%20President....

Bobo on the server would then turn that into a traversal path and method call, like:

root()['people']['johndoe'].setJobTitle(jobtitle='Vice President....')

And all that John Doe's class might have to do is something like this:

class Person(...):
    def setJobTitle(self, jobtitle):
        """ Update the job title for this person """
        self._jobTitle = jobtitle

That's a very simple example, but not really that far of a cry from what I still do today. In fact, using Ajax and Zope 3 has been extremely easy because of things like this, and I have some MochiKit based helpers that let me construct Javascript client objects to server side 'browser views' (which are also being controllers in this case) to do operations that are very similar to the simple example above.

It's now been about nine years since I started programming Python. For almost all of that time, I've developed for the web. And for all but the first seven or eight moths, I've used Bobo or one of its descendants. Now I'm using Zope 3, which is the completely re-architected Zope framework and application server. And I'm amazed at what we've done in the past month and a half on it. We've watched so many frameworks and concepts come and go, go into vogue and then out. All this time, Bobo has been sitting at the heart of Zope and even larger systems built on top of Zope (CMF, Plone, CPS, to name a few), doing the simple job of publishing objects on the web. How complex and overburdened those objects may have gotten in Zope 2 is a different debate. For as long as Django has been alive as an internal project before bursting its way onto the public scene recently, Zope and the CMF have been quietly and steadily managing many large television and newspaper sites around the world.

On fads... I remember fondly when it seemed of utmost importance to make Perl work in or with Zope. And then it was Java - "yeah, but could it work with J2EE / JSP?" and early PHP. But I believe that the core Bobo ideas are still extremely valid. Because although Zope 3 is a new and clean architecture compared to the jungle of Zope 2, the principal ideas (and even some of the very core code) seem to have changed very little, even as other trends have come along for the rest of the Python community to try to duplicate... I never understood servlets in Java. And the Python implementations were even harder to understand. Bobo... I got it.

Throughout the years, I've been fascinated by compound document technology. I still pine for OpenDoc. Most of my work has been on the web, and every few jobs I seem to come into doing content management and every time I do, it's seldom as simple as "entering some text on a page".

I have proposals, diagrams, and outlines going back to my previous major employer. But most of my memory of getting to really deal with the problem stems from my time when I came back to Utah. I continued to use the Zope platforms through various stages of minor and self employment before landing in my current situation (where Zope is still used). Three generations of working with building compound documents come to mind.

Generation 1 - CMF Based, OpenDoc Influenced, Dynamic Structure

We had a customer that provided us with the basic structural layout of the site that they needed to manage. They needed to be able to add new pages, and those pages needed to include images, lists, etc, as well as text. I decided this was a great time to try my compound document ideas. Taking a page from OpenDoc, I decided that a document was a very basic element that was just composed of parts. In fact, the Document basically held a 'root container' part. Container parts held other parts, such as text, images, and so on. Parts could, theoretically, be quite complex. Container parts would manage sub-part creation, access, and ordering. In implementation, I believe they derived from Zope's ObjectManager base class(es). For this customer, they could create a new document and then just add parts to it. They could only edit one part at a time, but its editor would display in-place with the rest of the document. Parts could also be re-ordered. Images could be dropped in between paragraphs and told to flow on the right, left, or center. The content editor did not have to type in any code to refer to images. Navigation to other documents was also managed by another drop-in part. Most folders have index pages that contain a navigation part (listing sibling and one-folder-down content) and a text part to give a folder table of contents some meaning.

This was a pretty good system. Unfortunately, it was developed at a time when the CMF (Content Management Framework) had stalled out, it seemed, with releases. It's since picked up. But we had basically a munged version on our hands.

We were able to take advantage of much of what the CMF offered - indexing, workflow, user management, and a nice separation of UI code from content (which can sometimes be tricky with Zope 2 development). I still felt very frustrated with the experience though. It felt like I had to do too much work to get the CMF to get "out of the way" where I needed it to in order to satisfy my customer's needs. While the CMF paved the way for Zope 3 by providing some much needed new concepts to Zope development - replaceable components, service/policy objects that were easy to look up and use while also being configurable locally, the concept of "skins" to build layered and swappable user interfaces, the ability for many objects to participate on behalf of a basic content object so that a document could just be a document - it always felt quite heavy to me. Starting out with it from 'scratch' without the default content management application implementation was overwhelming. Hiding much of the default implementation was tedious. And to me - it's actually quite a nice system. It was often just too heavy for our customers budgets or our own time constraints.

But that system that I built - which was for a non profit literacy group - is still in use today and has more content than I ever envisioned. My own struggles with getting my implementation going put aside, it's not a bad system and I'm glad that it still sees use long after most of those involved with the launch of the project have since moved on. Later, when other small companies and organizations came to us with need for simple content management, I felt that a different approach was needed.

Generation 2 - Pure Zope, 'CMF Lite' in a way, still OpenDoc based, fixed structure

For the second generation it was decided that we needed something that was more directly under our control and understanding. It didn't need to solve all problems at first, but it should be flexible for growth. I had recently gotten a lot of benefit of implementing and deploying D4 (Dynamic, Declarative, Data-Driven) architectures on Zope, whereby model designs were used to dynamically build user interfaces, provide validation, and so on (things that are increasingly taken for granted today, but seemed to take a long time to come around to). Most of our D4 solutions at that point were against relational databases, with one application tied to LDAP. I wanted to take what we had learned and applying to these content documents. We had customers coming to us now that didn't have such free form content, but instead had pages that held more common structure. I wanted it to be easy to define this content and store it in the ZODB while having my code avoid direct use of the Zope 2 framework if possible. The new solution consisted of:

Parts

Still the chunks that documents were made of - parts were separate but complete small content items. A part could be text, an image, a headline, or any kind of structured record (contact information, links and descriptions about last years festival, etc).

Policies

There were policies for folders and for documents. This is where a lot of the pluggable and extensible architecture came from. Folder policies would set things like "what is the default document to show for this folder?" or "what kind of documents may be added here, and how many?". They also provided APIs for listing and organizing content. An events folder might plug in an event listing policy that would sort events on their starting time. Like CMF Tools, policies had interfaces and common names, and you could replace them at will. Unlike CMF Tools, folder policies were kept in a special containing object on folders. There were no global site settings (although I've been wanting to add this feature). Documents got their policies out of a document policy manager.

Document Schema

A document schema basically put the parts together that would make up a particular document type. A 'contact information' page might have a text part, a picture part, and an address part. The schema was just another policy on the document type. The schema policy was also responsible for getting form data out, validating it, and saving it.

Simple Events

The individual policies for a folder or document could respond to events that were passed on from the containing policy manager. The Schema policy would respond to a 'document added' event and populate the document with empty parts based on the schema definition.

Skins, and composable interfaces

Another common policy was the 'views policy', which said which template/view objects to use. These objects were given common names, like 'edit', and could be configured differently for different skins. The skins tool we used was written by Chris McDonough and was basically lifted directly out of the CMF. Skins are built into the CMF and Zope 3. A skin is composed of layers. View objects are assigned to these different layers, and basically the view object is looked up in each layer until it is found. Thus you can have both an 'admin' skin and a 'public' skin. In each case, objects are traversed to directly (this is Zope after all). But how they'll be rendered and controlled depends on the skin that's placed on top of them. It's not a great explanation, I know, but it's a pretty significant concept.

Basically, what I had managed to do was mimic a lot of functionality that I liked about Zope 3 (which was still deep in pre-release development at that time). It's a successful system - I was even able to integrate it into our e-commerce solution which is a very different styled application. It even reuses a fair amount of code from the first generation, since many of the internals (documents and parts) were CMF agnostic.

The big difference between the second generation and the first was the move away from free-form documents. The system could allow them with some other policies plugged in. But the advantage of the rigid documents is that we could design certain pages more easily because we knew exactly what slots were going to be on there, and what slots might be on there. The customer still has flexibility with the content that they can enter, but the pages are crisper than they might be if all we could to to render it is loop over the parts and tell them to draw themselves.

Generation 3 - Zope 3 based. No OpenDoc heritage. Lightweight, in less time

The main reason that I'm writing this entry is that I didn't realize until today that I had basically redone much of the work from Generation 2 in a customer application we're developing in Zope 3. The concept of parts are gone. Generation 2 schema was defined through the web. Generation 3 uses Zope 3 concepts. Instead of parts, Fields are used - even for complex objects. A page is defined through its Interface, a very strong Zope 3 concept. And that interface's schema is then used to build edit forms and has provided other exciting benefits as well. For example, I can take any of my content objects and find all of their fields that have text in them that can be used for indexing. The field in question might be simple - just a line or block of text. Or it might be complex - like a table with a title, a caption, and rows of cells. In fact - it's this table field that I wrote that made me realize that I had already made a more complicated 'part' than I had ever made for either of the previous generations. And it wasn't until this evening as I was showing progress to my boss that I realized that this set of work - much of it done just in the last three work days - pretty much blows away the 2nd generation.

Zope 3 delivers a lot of functionality that I can then build my own application stack on top of. It's very rich, like the CMF. But at the same time, it doesn't feel like it gets in the way nearly as much. It's still a rich and complex system - you can't really write a "20 minute wiki demo and video from scratch" on top of it without also having to explain the default user interface or skin configuration or URL namespaces. But at the same time, many of these concepts are (relatively) easy to deploy when setting up a new application. This one that I'm working on I've been at for less than a week now. And it's pretty much caught up to our first 'generation 2' site which took a few weeks, mostly because the Generation 2 compound document system was being written along side with it. This 3rd generation implementation is still missing some key elements that I'd like to have implemented, but I don't think they'll be that big of a concern. And the UI is much more impressive than anything we've done in the past. Thanks to MochiKit and much of the work done for the customer prior to this, we have a nice dynamic / AJAX based UI with sortable folder content listings (in javascript). Drag and drop content reordering. Inline renaming and retitling. In the past couple of days I've written a complex Table field for Zope 3 and gave it an interface that allows for dynamic Javascript editing (adding / removing rows - the column definitions are fixed). In less than an hour today I wrote a Textile field (basically a plain descendent of a text field), whose widget uses AJAX to allow for in page previewing of the Textile output.

And all of this is within an architecture that I understand. Granted - there are a lot of Zope 3 concepts that one has to learn, and there are many that I haven't learned yet. But even my own "Generation 2" system I had trouble understanding in comparison to what we've done on Zope 3. The deep dark caverns of the "Generation 2" schema system - which is quite powerful - are scary places for even me, the author, to go.

What impresses me most about Zope 3 is how easy it is to build ones own layer of toolkits / frameworks on top if it all. A common stack we have, which came together within the first week or two of using Zope 3, is this:

• Customer Specific - skins, components, utilities specific to this customers needs. May build on the next layer.


• Similar Customers - content and utility components that are common across a certain set of customers, which is the situation we're in right now with this first batch of Zope 3 work.


• Our CMS / Framework - Provides the management UI, common components, configurations, etc, that are common across many sites that we expect to build.


• zope.app - The Zope 3 application framework. Provides many of the basic components for a full Zope 3 application - containers, utilities, apis, etc. A pretty beefy layer.


• Core Zope 3 systems (zope.interface, zope.schema, zope.component, persistence, transaction, etc). These are the basic layers underneath Zope. One could, in theory, use many of these outside of 'zope.app' to build a different application server that did not depend on or provide much of what zope.app requires. There is a 'bobo' branch, for example, which builds on just a few of these core things. Using the zope.bobo, one could in theory write a 20 minute Wiki or 20 minute todo-list in a manner similar to what Rails or TurboGears shows off.

Along with all of this, there are other python libraries, including internal ones, and Zope 3 based libraries like Hurry, used as needed.

What surprises me most of all is how quickly this latest solution came together, almost without my seeing it. Nice.

A cool photoset on flickr: "Apple's Front Pages Along The Years". Going back to 1996, it includes a couple of captures from the Amelio years. I remember that site. Apple at that time was quite large and sprawling and many sites were off on their own subdomain with their own look and feel. There was a trove of information out there on projects like the Dylan Programming Language as well as OpenDoc, Cyberdog, and a browser plug-in called "HotSauce" which could fly through MCF - Meta Content Format - data in 3D. MCF would go on to eventually become RDF.

The photoset includes NeXT's page at the time of the Apple-NeXT merger, which was a very exciting day for me. That merger literally set fire to the company. All of the excess was trimmed, and eventually Apple started the "Think Different" campaign and launched a new web site in 1997. By the time the iMac was announced (with the campaign of "Pro. Go. Whoa."), Apple's home page has stayed pretty much the same in the time since then. There's the big picture, the "hot news" scroller, and now four cells underneath (there used to be just three). It's interesting to see such consistency on a major corporate web site.

I saw a link to this today - a list of Python anti-pitfalls, written back in 2003 by Richard Jones. There are a couple that I'd like to add boisterous comment to.

11. No namespace pollution (unless you really want to)

Unless you explicitly do from foo import *, all names are contained within modules / classes / objects. I love Python packages and modules. Every time I work with another language, like my rare excursions into Perl or Ruby, or my recent working with Javascript, I'm reminded of why I love this feature.

from zope.interface import Interface
import zope.schema

class IFoo(Interface):
    title = zope.schema.TextLine(...)

A very simple example. But in Ruby, for example, require 'xml/parser' is then used in code as XML::Parser - a name that is similar but different to what was in the require statement. In Python, that might look like import xml.parser and then be used as xml.parser.Parser. The last time I used Perl, I was always staring at names that I needed to use and wondering exactly where that name came from. I use neither language enough to know the difference between 'require' and 'use' (PHP suffers from this as well). Python's Modula influence is perhaps one of its strongest features. It makes large frameworks like Zope 3 and Twisted actually quite easy to understand and follow.

So with Python, every name that I see in code I can easily trace, unless the code's author uses multiple 'from foo import *' style statements or does some namespace manipulation magic. I try to avoid those these days, wherever possible.

12. The python shell (interactive interpreter)

I learn best by trial and exploration, and the excellent Python interactive interpreter is probably the number one reason that I'm a Python programmer at all. I was raised on computers like the Commodore 64 which pretty much had the BASIC language/environment loaded at all times, so I could immediately try out small or large chunks of code. Python was the first language since those early days that brought me the same joy. On a daily basis, I still drop into the interpreter to introspect objects or just to try out how something might work. For learning something new - I recently used the interpreter to figure out how to dynamically build a zip file of CSV files while never actually building a file on the file system. I was able to explore using the csv, StringIO, and zipfile modules together in the interpreter before integrating the code into my project.

Recent versions of Zope (both Zope 2 and Zope 3) make it easy to load up the Python interpreter with the ZODB and Zope system loaded. I was able to use this the other day to dig deep into some indexes to figure out why some search results weren't behaving as I expected. It turned out that I was querying the index incorrectly, but it was a behavior that didn't show itself based on the first set of data that was loaded in our ZODB database.

This interactive interpreter is available at all times. It is Python. It's one of the many features that makes working with Python without all of the weight of an IDE possible.

13. PDB

PDB is the Python debugger. This is the other feature that makes working with Python without all of the weight of an IDE possible. Sometimes, I have problems in Zope that can't be figured out with some other debugging means (logging, etc). When running Zope so that it doesn't detach from the shell, having the following statement in the Python code: import pdb; pdb.set_trace() basically puts a breakpoint in the code and when those two statements are executed (the pdb module is imported and the set_trace() function is called), Python drops to a 'pdb' shell inside of the interpreter. From here, I can step through code, inspect variables, go up and back down the call stack, and even import and use other code to help me in my inspection. When the problem is solved, deleting the 'import pdb; pdb.set_trace()' line is all that's needed to remove the breakpoint. Again - this is doable without an IDE and is available anywhere - even on the most stripped down server configuration.

There are many other anti-pitfalls in Python in Richard's list. These three (which just happened to be sequential) are the three that I'm most grateful for and are all elements of Python that I've used happily for almost ten years now, even while other new (and welcome) features and modules have come into the language since those Python 1.3 days.

Microsoft has released initial information and screen shots about Office 12. It is a complete revamp of the user interface, at least in the primary applications Word, Excel, PowerPoint, and Access. The "authoring" components of Outlook (message composition) have also been affected. So now it's time to weigh in with my own thoughts about the whole affair.

Visually, many of the applications remind me of Apple's professional applications like Final Cut Pro or even the iLife apps like iMovie. Many of the new office applications feature a brushed metal interface, similar to those seen in some Mac applications in recent years. But the similarity doesn't end there - Apple's metallic video, photo, and audio tools all do a lot of functionality within the window with sliding drawers, tabbed sections of the interface, contextual toolbars within certain frames, and so on. This is something that seems to work well in these kinds of applications. But Microsoft seems to be experimenting with taking that sort of experience to the office suite. I'm not saying that they're copying Apple (although the brushed metal AND aqua-type tabs are rather interesting). I'm saying that it's a unique time in user interface design. Office applications have been pretty much the same for the past decade, especially since Microsoft Office started its total domination with Office 97. Since then, it seems that the big changes in Office have been a large proliferation of "editions" which basically bundled different applications on top of the standard set. There have been some UI improvements. I believe it was Mac Office 98 or 2001 that first introduced the context sensitive formatting palette. This was a floating toolbar with expandable / collapsable regions that would add features based on what you were working on. This started showing up, more powerfully, in the windows version of Office, starting with Office XP, in the form of 'Task Panes'. To this point, task panes seem to be about the only major UI innovation in Office.

I should qualify all this by saying that I am not an Office user, nor a Windows user. I'm a Mac user and internet developer. Word processing and spreadsheets rarely cross my path. But I'm always interested in what's going on with major applications and user interface trends and I think that we're at an interesting time right now. Apple is making bold design decisions, some of which are hotly contested, but some of which have been wildly successful and I actually enjoy most of my days in Mac OS X. And I have to admit that Gnome is really doing an incredible job, I think, with bringing good and legitimate usability to *nix. I've even seen some Mac people joke about finding better consistency in Gnome applications than within Apple's own Mac applications. And now with the next generation of Windows coming up (Windows 2000, XP, and 2003 are all considered to be Windows NT 5.0, 5.1, and 5.2, respectively; 'Vista' is considered 6.0), Microsoft is showcasing some interesting UI design in their first beta. Looking at some screenshots of picture and video management, which is integrated into the Windows Explorer (Desktop, Finder, whatever you want to call it), I noticed that there is no menu bar. In screen shots of IE 7 Beta in Vista (Beta), I noticed that the menu and toolbar are relegated to being pushed deep within the window. The window itself is a unified titlebar and toolbar look, which has also been popular on Mac applications, and is most obvious in iTunes 5. In the IE 7 betas (which could change), the top is dominated by back/forward buttons, the location field, and a search box similar to that seen in Safari and Firefox. Beneath that are tabs for tabbed browsing, and then within that is the menu bar and a toolbar providing other IE functions (home page, print, etc). That interface is too strange, I think. It's not a problem for Macs to have the big toolbar - our menu bar is always at the top of the screen, not having to fit in a window. But on Windows, the menu bar is starting to have a new life, it seems. At least in some core system functions, and in Office 12.

Office 12 seems to do away with all menus, except for 'File'. All other functions provided by menus are now in major tabs across the top of the app (which replace top level menus, it seems), which provide big toolbars for that area of functionality.

Does it work? I don't know. I haven't actually used it and it's not likely that I ever will. At times, it looks like early WYSIWYG tools that ran full screen in DOS or on whatever machine they were on at the time that didn't have a real windowing environment. The tools seem kindof big and clumsy and put there because "where else are they going to go?" and they end up taking half the screen... But that's just what it reminds me of at times... something out of the late eighties / early nineties. At the same time, it reminds me of Apple's professional video applications. In iMovie, Final Cut, iPhoto, etc, you have one main area of content that is focuses on, and all of these other tools surrounding it that tend to stay out of the way of the content area. That's not bad. Even as I'm writing this entry in MarsEdit on the Mac, my focus remains on this window where I'm typing and I go to the toolbar on rare occasion and to the menus even less. Granted, writing this entry is much different than what Office is geared for, but I admit that I never feel this comfortable when I have to write something in Word. Word just doesn't stay out of my way when I need it to stay out of my way, and I'm certainly not a powerful enough user to deal with it effectively. So it seems that keeping the authoring area in better focus is a bigger design goal in the Office 12 UI. I like that, at least in theory.

There's a big problem with Office. The brand is so powerful that, like Photoshop, many people are trying to use these very powerful applications for very simple tasks. Many people probably end up with a copy of Office even when something like Works or a third party solution might do. There are probably people who need all of the power of Word and Excel, but I wonder what percentage of Office users they represent? And the open source contenders? OpenOffice.org seems to just be trying to be a free version of Office, which I'm not going to argue is a good or bad thing, just that it's probably even more developer driven and less user driven than even Office has been. Compare this screen shot OpenOffice.org Writer with this shot of Word 12, both of which are unreleased, I should add. Comparing the two, I'd take Word 12. The shot of Writer reminds me of the biggest beef I have with all versions of Office since at least Office 95 - way way way way way too many toolbars full of buttons that I can't differentiate from one another, let alone discern at fairly rapid glance the meaning of all of those icons. If nothing else, I'm happy to see Office finally pull away from such horrid toolbars and providing more text options. I'm also glad to see Word pull away from it's endless litany of menus, menus that I found to be too confusing back in the early 90's with Word 5.1. 5.1!!!!!! Why did it take 12 years and six versions to start changing that? Granted - Microsoft has tried some other approaches in the intervening years, such as 'smart menus' which tried to hide less used items, contextual 'smart tags', task panes (which I actually enjoyed using in my evaluation of OneNote 2003).

Anyways - Office, its clones, and other similar suites that may still exist, are so ubiquitous and overpowered that it's no wonder that there are so many grievances against them by many users. Microsoft has had a hard time selling new Office versions - not an abysmal time, but they have a hard time convincing people to upgrade. Why upgrade to something that's probably only going to be more complex? Perhaps Office 12 is an attempt to combat that perception. But here's my suggestion - learn from Apple. Office is a professional application. Market and sell it as such. Really revive Works as something like "Office Express", or make some other still-powerful-but-not-overpowered version of Office as such. Get away from all of those different editions and their confusing combination of programs. Stop selling individual programs for so much when the office suite with so many more options is not much more - either sell them for cheap, and/or provide build to order licensing so someone can get Word and Outlook for cheap. If I had Windows, I would never go near Office because the different 'editions' are confusing and often too pricey for a casual user. If you (Microsoft) cannot provide to people looking for simpler and cheaper solutions, others will step in. The Office 12 UI changes look interesting, but will they be compelling? Will the cost and licensing be worth it? Will anyone else step up to provide alternatives for more general usage? Will users notice?

If the planned Windows Vista editions (of which there are 7) are any indication, Office 12 will probably fall victim to this same thinking and users will be presented with huge product comparison grids and confusing pricing and licensing schemes. If OpenOffice.org has their stuff together, this is a strong area they should compete in. "Want a word processor? It's free. Want the word processor and the database and email? Same price". Now if only someone like OpenOffice.org, or Gnome, could start taking a look at real usability issues. Because you know - I really do like what I'm seeing from Word 12 screen shots and videos. Fortunately, on the Mac there's Pages from Apple and Nisus's Writer Express as cheap, native, and usable alternatives to Word should I ever really need them.