John Gruber of Daring Fireball writes up some issues with the Safari User Interface. I have a couple of counterpoints to some of his points:
I like the way Safari?s bookmark system works. I like the iTunes-like interface, and I really like the way that you don?t have to display all your bookmarks in the bookmarks menu. Nice.
But I don?t like that the Bookmarks window isn?t it?s own separate window ? like Downloads and Activity are. Instead, the Bookmarks window is displayed inline within any regular browser window. I?ve tried to like this, I?ve really tried, but I don?t. Plus, it?s somewhat confusing. When you?re displaying Bookmarks, the window title and Address Bar still display the name and URL of the web page behind the Bookmarks. But they?re not visible. [Gruber, John "When in Rome" Daring Fireball 07 Feb 2003]
Personally, I really really like Safari's bookmark handling. I like that they open in the same window. The screen in question not only manages bookmarks, but is used to open bookmarks in the same window. I use it frequently when dealing with the new army of bookmarks that I'm building that I don't want populating the quick-link bookmarks bar, or the bookmarks menu. I especially like the existence of the History item included in the list of bookmark items. The bookmarks view pops in and out so quickly that it's a joy that it's there. I don't want another window floating around that I have to pop to just to get to this list - I find this annoying about most other browser bookmark management systems, which is why I think most people's bookmarks in these systems are such a rats nest of links. People just hit "add to bookmarks", but never want to deal with managing them. Safari puts a nice UI on bookmark management (which Mr Gruber does like). It just also happens to combine bookmark management with actual bookmark usage.
What would happen if I had many windows open, one of them being the bookmarks window, and I'm cycling through them to find said window to navigate to a site that's not on my bookmarks menu? Which window would it open up on? The first window I was on when I started hitting the window-cycle key chord, or the last window viewed prior to finding the bookmarks window? I'm happy with this feature as it is. The one thing that I wouldn't mind is if you could toggle the "open bookmarks in new window" feature by holding down the command key when clicking (the general Mac browser key/mouse combo for "open link/bookmark in new window").
Mr Gruber also begs for abandoning the brushed metal skin. Personally, I like it. This one's a matter of taste though. I hope it stays, though. Some of the widgets (particularly the "search google" widget's resizing capability) don't quite match up to general Aqua toolbar expectations, but is a very handy thing to have in its own right.
I find Safari to be beautifully simple and fast. I want it to keep both qualities, particularly the simplicity. I'd rather time be spent addressing the remaining HTML rendering issues (ie - Plone sites have rendering issues, mostly dealing with CSS padding it seems; Safari also seems pretty random about how well it handles THEAD/TBODY/TFOOT table parts) than on weighing down the interface and preferences system with unneccesary components.
Jon Udell has a piece in the latest Infoworld cites the recent series of interviews with Guido van Rossum by Bill Venners. Jon talks briefly about the pre-J2EE days when it was generally speculated that most Java servers would be prototypes in portable code, and then compiled to native code. This apparently has not happened, and Java application servers continue to run happily in the JVM.
Of course you dare not build the application server itself in a high-level language like Python. Not, that is, unless you're a quiet revolutionary like Zope Corporation's Jim Fulton, architect of the Python-based Zope application server. [Udell, Jon. "Shipping The Prototype", Infoworld 06 Feb 2002. 07 Feb 2002.]
I'm in the process of wrapping up an intense little customer project - that is on schedule - done in Zope. The project is interesting because we took a different route to development than usual. Many of the custom Zope applications that my team develops are SQL backed, and are fairly analogous to many PHP sites: scripts and templates and SQL code making up the bulk of the application. This time, however, we've done entirely custom business objects written in Python and stored in Zope's object database. As I mentioned recently, this is sometimes a tricky venture in Zope 2. But it's paid off. We're on schedule, and this includes responding to a fairly significant change request from the customer at our first milestone meeting. I expected this change to push the deliverable date for the project back a couple of days, but the architecture absorbed the changes (fairly) easily.
An interesting bit from this project is that we need to store some fairly flat data in order to accommodate these changes. My boss kept saying "Oh, we'll just stick it in Gadfly [a simple pure-python relational database] or something." Instead, I made the decision to use BTrees, and represented the data needed as small Persistent Python objects; to speed up the requisite queries, I added a couple of BTrees to act as indexes. My boss's (valid) concern is that an object database like the ZODB just doesn't have the same memory and write optimizations as most relational databases. I'm hoping this project will give us better footing to do more pure Python Business Object based development in the future (where it fits the bill) as we start to look ahead to Zope 3.
Considering the architectural implementation, the requirements, the short time frame, and the very large possibility for expansion if the project in question actually gets used, I could not imagine doing what I just did in anything but Python, and with any application server but Zope. Fundamentally, I could have gone with the servlet based WebWare and delivered the same business objects, but I would have been on my own when it came to persistence, security, and user management.
Jon Udell says "the classic phased life cycle of software development -- design/develop/test/deploy -- is dissolving into a continuous process." While the mode of development (at least, on project's that I maintain) vary from project to project, it's quite something to be able to show a milestone release instead of a prototype and be able to respond to changes in a timely manner; instead of showing the prototype, getting feedback, and using that feedback to make the "real project". In the last six years, especially, I have never seen one "throw-away prototype" (encouraged by some development processes) actually get thrown away.