Some critical comments
First of all: I use CityDesk, and in principle, I love the concept.
However, CityDesk is not perfect. Some remarks:
1. The HTML Editor
This is the large problem of CityDesk! There is a *very* good XHTML editor available, which supports fully XHTML (yes, with table & with headers) and real CSS support(!!): XStandard! This editor is designed to be integrated into a CMS. Although the web service cost money (cheap!), the ActiveX control is free.
Very good that CityDesk uses standard Access database. Very bad that the most important thing, the article, is saved as a blob!
4. New version, new features
I could imagine why Joel will not discuss/announce features and release dates. But Joel should know that we, the users, need both information!
Since CityDesk 2.0 does not support multi-level menus (and some other features), I have implemented this by myself. If next week the new version comes out that supports these features, I am not sure what I should be: happy or furious.
Why not voting for features on Fog Creeks web site?
I found some really ugly bugs and problems in CityDesk. For example, adding a second language lets CityDesk publish into sub folders. Each folder has the same name as the associated language. Above these two folders, a file "index.html" is created, which gives you an overview about what was published. So far so good. If you now delete one of the two languages, no sub folders are used. This means that CityDesk goes back to the original "one-language-behaviour". But CityDesk still continues to create a page "index.html", what now means: my own "index.html" is overwritten!
Such a bug (reported today to Fog Creek) needs to be fixed within, say, 1-7 days - sorry Joel.
Analogously the same is true when a feature is needed that is very close to a bug.
For example, if you use an external program to polish what CityDesk has published, this external program don't get the information WHAT DATABASE is the source. This means I cannot save my "own" data in this database in my own table(s), and I could not access any other piece of information saved by CityDesk. This is bad design. Should not happen but happens, since this world is not perfect. Simple solution that could be implemented without the danger to affect existing CityDesk applications: add a Build-In-Variable "DatabaseName".
Using the "publish" button from within the article editor is fine to save time, when I am interested in this article only at the moment. But my external program don't get the information that only this certain article is going to be published now, so all (!) pages are polished every time.
Since the editor XStandard is available now, I am thinking about writing the rest from scratch. This will allow me to add:
- Auto-Creation of multi-level menus
- Different default templates for every folder
- Automatically created bread crumbs
- ... (numerous other ideas)
with an editor that seems to be nearly perfect.
Why I am not doing this?
Because it takes a significant amount of time to make it work for me. And much more time to make a real product from this (= make it working for others). So I would prefer to use CityDesk - if there is real support with bug fixes, an understandable release policy with information about release dates (not exactly, but an idea) and features added for sure / not for sure / perhaps.
Saturday, May 1, 2004
> Since CityDesk 2.0 does not support multi-level
> menus (and some other features)
> I am not sure what I should be: happy or furious.
Always be happy :-) BTW, our next Wizard, VANTAA, will be released next week which does exactly that (finally): automatically create unlimited menu-levels.
Really automatic: a 1-to-1 projection of your article/subfolder structure in CityDesk to the dynamic menu system of your website.
Congrats to your solution and those are some valid issues you air, thanks.
Saturday, May 1, 2004
Fog Creek Home