| David Ness |
| Mind / Matter |
By David Ness
Wednesday, January 16, 2002City Desk
I have had the pleasure of using Fog Creek Software's City Desk as the principal vehicle driving my Web site since the very first days of the initial release of this product. It has been a delightful experience. However, no piece of software (at least in those I've encountered so far) is perfect. There are always some things that might the software even more effective as far as particular users are concerned.
As software becomes more complex, it is harder to guess the practicality of the suggestions that one makes. As a result, the suggestions contained in this note may be impractical, but that is difficult to judge without more knowledge of the structure of the software than is likely for a user. In this particular case, the software proves to be very useful whether the suggestions ever get adopted or not. In any case, nothing is lost making the suggestions.
So, let's start by giving a brief overview of the incorporation of City Desk into my Web site, followed by a commentary on some already published critique written by other users. Then we can turn to some of the suggestions for future development.
First Steps
The first steps were remarkably simple. An uneventful download, followed by a completely uneventful install on several separate systems, WinME, Win2K and NT4.0 in particular. All of the installations proceed without problem.
After installing City Desk I took some CSS files that I had for other purposes, and using a prototype INDEX.HTM page developed from an example provided by another early City Desk user, I was able to get a draft of a new home page ready quite quickly.
Most of my documents are generated from a very simple intermediate language that I created for myself some while ago. This language follows rules quite similar to REBOL's (Sassenrath and Muench) make-doc files or to the Almost Free Text system developed by Coram and Cunningham. Both of these systems involve storing text pretty much in straightforward simple ASCII, with only a very small amount of mark up.
In my case, adapting these files to City Desk was rather simple. Mostly, a few simple edits got rid of some of the few remaining markup characters, and then some titles that came through the process as simple lines were re-marked as HTML headers. This, along with some search and replace operations to replace various bold and italics placeholders with the corresponding HTML proved to be all that was necessary to obtain decent draft documents.
As will be discussed below, I am only unhappy with one aspect of this process---it is currently quite `one-way', by which I mean that it is easy to translate my existing documents into the City Desk milieu, but at the moment I have no constructive process to go the other direction. I have satisfied myself that it will be possible to do so, when I need to do it, but at the moment it wouldn't be easy.
I found it quite startling how simple it was to turn on my new Web site. The fact that City Desk managed to handle all of the accounting for files made it a one-button publishing solution that delighted me by coming up without difficulty within a small number of hours after my first encounter with this product.
Another very pleasant surprise was the fact that the whole complex of City Desk information was kept in one single file. This enormously eases the task of managing a site like mine where I am prone to work on the site on several different machines. As long as I am sure that I am working on an up-to-date copy of my .CTY file, I know that I am working with the latest versions of all of my documents. This considerably simplifies both the management of the information and keeping a good backup of the site.
Of course, I had some questions at the beginning. Instead of the usual suggestions that I RTFM that seem to pervade so many environments on the net, the City Desk Forum proved to be very helpful and remarkably courteous. One particularly pleasant surprise was that it was not only the software designers who were courteous---since they have a product to sell that's not really a surprise, but also the other users. Perhaps if people are generally happy with the software they are using, they are somewhat less prone to engage in the nasty interactions that seem to be common in other Net environments. In any event, both the designers and the other users were generally very pleasant and helpful.
Other People's Impressions
Impressions of City Desk are beginning to appear. So far all of the ones I have seen are quite favorably disposed to this product. In one set of very useful remarks Darren Collins gives some suggestions which are both worth repeating and worth commenting on. He writes at:
http://www.pool-room.com/CodeCraft/CityDesk/fog0000000004.html
It wouldn't make any sense to disagree with the wishes expressed in any such lists. We all just have our wishes and wants. However, while I agree wholeheartedly with Collins' positive sentiments, I want to express a completely different set of desires for the direction of City Desk's evolution. I have quoted Collins' comments in italics in the notes which follow.
I want to be able to write articles for my web site in a simple format (giving me hyperlinks, bold, italics, fonts, simple tables, etc), preferably using a WYSIWYG editor. I don't want to have to write them in raw HTML.
I don't share this wish. For me, learning `another editor' is a bigger pain for me than lapsing into occasional HTML to express my wishes. And I think there are just too many options that I might want to use to implement special technology to handle each of them effectively. What would make me happier in this regard is a very simple thing. It is somewhat more careful locating of the cursor when switching from the normal view into the HTML view. That would make it convenient to generally edit the articles in normal mode, and yet ease the transition into HTML mode anytime that proved to be necessary.
I want to be able to create a template for the pages of my site. This way, when I change the design, I only need to change it in one place, not 50.
My CSS templates seem to me to do this pretty well, but it does provide me the opportunity to express one related problem: color in rendering.
I am startled by the how different pages look when rendered on different screens and with different browsers. And in my life, there is an additional complication, I am one of the 5+% of the American Male population that happens to be color-blind. This adds a further dimension of complexity.
It is becoming increasingly clear, in my world at least, that I will never be able to test all combinations of screen, browser and color-blindness (there are several different types and varying levels of severity). As a result, it would be very helpful to me if it was easily possible for the reader to hit a button and change the color scheme, hopefully allowing them to find one which will make the text which otherwise disappears into something that is readable. While this might not completely solve every problem, it does at least afford the prospect of making some relatively simple experiments as reports of reader confusion come in.
Of course, not knowing implementation details, I have no practical idea of just how much this is asking for. In any case, I discuss this point in further detail elsewhere in this note.
I want to be able to store extra information with my articles - things like a teaser, a sidebar, the author's name, the date it was created, a title, topic, etc (honestly, this is true - it's eerily close to what CityDesk provides!).
I agree with this request completely. And it seems to me to be squarely in line with the general design philosophy of that is a basic part of City Desk. The more meta-information that we can regularize the storage of, the better off most of us will be. I have already used `Extra 1' and `Extra 2' for some (regular) purposes, and want more.
When I write a new article, I want it to magically appear on the site without me having to edit any HTML files. I'd like to just click a button or run a script to regenerate the site's files and FTP them to my web server. I don't mind if the FTP bit is manual.
It seems to me to work pretty much that way already. Perhaps it's just that City Desk already fits well with the way I happen to write text/HTML.
I want a simple navigation system for my site (not JavaScript, just plain HTML) that doesn't need to be manually modified every time I add a new article. The menu bar should be automatically built based on the topics of the articles in my database - e.g. house, garden, holidays, camera club, programming, etc.
I may not understand this one properly, but if it is a request for hierarchy in folders then I think I agree. I find navigating the folders in City Desk to be quite convenient, but I would be happier if it were easy to have some folder hierarchy.
I'm interested in digital photography, so I'd like an easy way to store information about individual photos. EXIF data (e.g. shutter speed, aperture, date/time, etc) can be extracted from the original jpg file, and I'd also like to add a caption, location, photographer, accessories used and a description.
Discussion follows the next paragraph.
I'd like an easy way to reference photos from articles, and have thumbnail images automatically generated for me. I want those thumbnails to click through to a web page containing a larger (e.g. 640x480) automatically-generated version of the photo along with its stored information.
This sounds a bit too specialized to me. Perhaps it's just that I don't do much with my digital photos (as far as my Web site is concerned, that is), and therefore don't recognize them as a particularly important special case of information. What strikes me would be better is to let this kind of stuff be done by application specific software, but have some relatively standard structures for absorbing into the City Desk world tables or little data bases that represent the extractions of such kinds of data. I'll make this suggestion more explicit below.
I'd like a way to manage resources as well - things like book and software reviews, links to other sites, etc. I'd like to be able to assign categories and scores to these resources so I can create recommendation pages, grouping them by category and listing the best resources near the top.
Again this sound a little specific to me. I can understand wanting to do it, but would opt for facilities that might make it relatively easy to adapt City Desk to such problems rather than to burden the core of City Desk itself with any such special code. I think there are some general purpose things that might productively be added to this software, but this strikes me as too narrowly focused to be a part of the basic core.
I'd like to be able to automatically generate plain-text newsletters from my content for emailing out to a distribution list. Failing that, see the next point...
I'm a programmer, so it'd be cool if the software was open-source or provided an interface to its database. That way if there's ever something extra I want, I can find a way to add it.
I'm going to discuss this point extensively in a moment, so I'll skip comment now, other than to say that it seems to me, at least at first glance, that there are ways to do this.
I don't want an application like Microsoft FrontPage adding heaps of garbage to my HTML - I'd like to keep it clean and simple.
I don't know enough about what FrontPage does, never having used it, to be able to comment on this point. However, I don't see much HTML `garbage' in the article files themselves as they are managed by City Desk, and I never end up by seeing what the real pages (INDEX.HTM, for example) contain, so I don't care about them.
I don't want a server-side solution, because I don't have access to install software on my host's server. I also want my data stored on my own computer where I can back it up, and I don't want to have to log onto the net every time I edit an article - I need to be able to work on stuff offline. My content doesn't change often enough to bother with generating pages dynamically - static HTML files are fine.
Pretty much as City Desk does, I think. Certainly it's a point I completely agree with in any case.
I'd like the software to run on either Windows or Linux, I don't care which.
Understandable. I'd implement in direct relation to size of user population, which I guess means Windows first, Linux second, Apple third, ...
Some of the places where City Desk has been discussed/reviewed:
Darren Collins' Site
The Dot Net GuyI had thought that Opinions and Editorials Online might offer some useful insights, but it seems to have descended into political tripe and has little City Desk content, so I reference it only in passing.
A Few Complaints
It just wouldn't seem right not to have a few complaints. What is remarkable in this case is that the complaints are so few.
One nattering problem is the maintenance of date and time information for the article. It would seem, first, that there is probably a difference between the official date that appears on a particular publication and the date on which the particular item (or some auxiliary file that is a part of the article) was last modified.
Second, City Desk seems to not attempt to locate the cursor at corresponding locations when you flip between the normal and HTML versions of an article. This would be a substantial convenience.
So would having a button to easily jump into an editor of your own choice.
City Desk's scripting language is somewhat limited, and it doesn't yet seem possible to have loops inside of loops. In my case, for example, it would be nice to have an outer loop that ran across folders while an inner loop ran across each document within each of the folders. At the present time this can only be accomplished, at least as far as I know, by explicitly writing out the outer level loop into a sequence of separate sequences that loop through each of the folders.
I would like a few more statistics to be maintained by the system. For example, a word count or a byte count is useful in maintaining an administrative overview of the content of documents that comprise a site. Suggestions made below may make this a generalizable process, thus leaving this kind of management control in the hands of the user, but if that is not done, then I would recommend that more be done directly by the system in this regard.
I can't figure out way to do HTML stuff directly in fields on the Properties and Extras tabs. It is important for both Properties and Extras. For example, author's names will occasionally involve an et. al. which I prefer to display in italics.
I also have a little difficulty moving folders around within a document. Even though the display order on the screen doesn't have anything to do with the order in which items are actually presented in my document, I find that keeping visual track of things is helpful. So far the only way I have found to do this is to move the folders one-by-one to accomplish the ordering I want. There ought to be (and perhaps is) a way to do this.
Undo seems unreliable. It seems to me that it works about 50% of the time, but I haven't been keeping careful statistics.
And, while it is a real convenience to have all of the information in a Web site stored in one single file, the way this is handled makes it difficult to detect changes on an article-by-article basis.
Added Capabilities
There are also some capabilities that would, for me at least, make City Desk into an even more comprehensive and useful product. Let's look at a few of them. A quick review first.
Import / Export of files There is a lot of data that we will not want to maintain within City Desk. For example, papers may be displayed not only on the web page, but also in Wikis or in printable documents. I don't want to be forced to manage the files within City Desk, and I want to be able to automate, at a minimum the absorption of files into the web page, and ideally to automate the output of the text that is being managed as well.
Editing I don't want to learn to use some new editor. In addition, many of the document that are to be made a part of my web site are generated by other processes. I do not want to have to re-format and restructure them to publish them.
Tables There needs to be some way to put tables on web pages as they are a basic construct for displaying all kinds of different pieces of information.
Outlines The outline is such a basic structure that it needs to be reflected in the organization of a web page. Section headers of different `levels' might nicely represent levels of an outline hierarchy, and I favor a `title line' followed by paragraph(s) format.
The `Look' Button
If it were possible, it would be nice to be able to have a button that allowed the user to change the look of the site. While this might be difficult to do as a general capability, the most important part of the problem, to me at least, is the ability to provide the site in different colors. This is important because monitors have very different rendering properties, and each user has different eyes.
Some users, for example, are color blind. I know. I am one of them. And for me some sites are impossible to read. I cannot see certain colors of characters when presented on certain backgrounds. Things that may be quite readable to most users may not even look like characters to me. If I could change the color scheme of a site easily, I might at least be able to read it, even if it didn't make it pretty.
Data Bases: De- and Re- Constructed
This is my most complicated suggestion. And if it is possible to implement, then it would solve a considerable number of the particular problems that have been raised above. However, it may either be too complex to implement or too prone to error/misuse. Nevertheless I find it worth thinking about. [Note: Some knowledgeable readers have pointed out that important parts of this suggestion can be accomplished by accessing a .CTY file via Microsoft Access. I understand that, but feel that such an approach requires considerable knowledge of Access, and that more might be accomplished by following line suggested here.]
The thrust of this idea is to provide a facility for deconstructing and reconstructing a .CTY file en masse. This kind of facility, if it were possible, would make it easy to have automated processes---or other kinds of functions---that would operate on the files that were created by deconstructing a .CTY file into ASCII parts. Once these were manipulated, the .CTY file could be reconstructed from the parts. Since most of the data in a .CTY file appears to be either strings or numbers, it should be easy to dump the data into ASCII files that could be manipulated by processes specified in just about any language.
While there are undoubtedly some dangers implicit in this idea, there are also several huge wins that are possible if it could be implemented. The most important of these is probably the fact that it would remove from City Desk itself the need to provide facilities to perform a whole complex of particular functional capabilities which, while very useful in some situations, might cumulate to be burdensome if lots of facilities were provided to cover lots of different specific circumstances. Fir example it might be nice to be able to check this note to see if the words City Desk have consistently been rendered in bold face.
It would also open the door to circumstances where text might be managed by some other process. I have mentioned above, for example, the fact that the majority of my documents are in a language that it is quite easy for me to render in HTML, but probably not very easy to go the other direction. Thus I would really prefer to continue to manage my documents my way, and incorporate them into City Desk by some automated process that could deliver the appropriate HTML forms to a deconstructed .CTY file. This could then be reconstructed and published.
If I wanted things like byte counts, it would be trivially easy to arrange to have them with such a scheme. Similarly for things like change histories or document cross references. Indeed, having the ability to deconstruct and reconstruct a .CTY file would open the door to being able to use the general capabilities of the computer to do all of those tasks that we might want to assign to it. Both the users and the City Desk developers would be freed from the burden of having to endlessly complicate the core processes.
It is perhaps also worth mentioning that the ability to deconstruct a .CTY file would also allow some differential analysis of changes in an article (or Properties item) to check items or to keep historical files cataloguing changes.
Outlines and Index Cards
There are two data structures that are of considerable importance to me when I deal with documents on my Web site that I do not find map easily into City Desk. They are outlines and index cards (`labeled paragraphs'). It would be nice if these were supported in some non-trivial way. While I have indicated above that I feel it would be inappropriate to burden the core of City Desk with lots of facilities that are only useful in specific circumstances, here we have some very generic and basic structures that might easily apply to many, if not most, of the documents that are presented on a particular site.
Actually, outlines and labeled paragraphs share a lot in common. The notion of a labeled paragraph is a lot like that of a simple index card. And as such it can be used to represent information in an outline. One way of looking at a conventional outline is to think of it as labeled paragraphs with null bodies set in a hierarchy. HTML makes it easy to associate particular typography with the various levels of hierarchy that are expressed in a document. The idea that each line in an outline can be associated with one or more paragraphs allows description of rich, structured documents.
Data on the Side
There is also the prospect of being able to store more information than is provided for in the current Properties list. It is generally safe to predict that no matter what Properties are provided for, and how many of them are provided, some users will need other properties. And they will need more of them.
The fact that City Desk supports the notion of variables is directed towards at least a part of this problem. However, in the current formulation, if I understand it correctly, variables are present on a per-.CTY file basis, not on a per-Folder or per-Document basis. Each of these might well have its place in a sensible overall site management scheme
Summary
To briefly summarize: City Desk is an excellent product, and delivers its capabilities with ease and clarity. There are a few problems and a few suggestions. Fixing the problems and implementing the suggestions would, in my opinion, result in a better product, but it is good enough, as is, to win the best of breed competition in its problem class.
David Ness' summary of work can be found at http://mywebpages.comcast.net/dness
City Desk is available in a trial version (size limited, not time limited) at http://www.fogcreek.com/CityDesk/.
City Desk's principal author, Joel Spolsky, has a blog called Joel on Software which is located at http://joel.editthispage.com/