Archive for the ‘badly designed frameworks’ Category

Why does Berkeley think it should be in the business of building its own content management systems anyway?

Thursday, August 27th, 2009

Brad Delong asks “Why does Berkeley think it should be in the business of building its own content management systems anyway?“.

His complaint:

May I say that a content management system that–if you have been off dealing with another crisis in the middle of a task–decides when you come back and try to save your work that you are no longer logged in and dumps you to a login page after which it dumps you not on the page you were working on but on the root page, LOSING YOUR WORK!!!1!!

Such a content management system is HELLSPAWN!! Is WROSE THAN HILTER!1!!!1!…

He is complaining about bspace, which is based on the open-source
Sakai, a content management system written in Java, and focused on the needs of universities.

I think Delong’s post is a good reminder of how infuriating it can be for users when software fails to behave in the ways users expect. I also suspect this is a good example of an issue that users will regard as a bug, but the programmers will see it simply as a potential future feature that they may or may not add (”Should we catch POST info if a user is not logged in?”).

I should add, WordPress has exactly the same problem. Last week I started writing what I thought would be a short post for this blog, but I got carried away by my theme and wrote a long post. Then I went to get some dinner. I left the browser open, with the post unpublished. I came back after dinner and made some more edits, then hit the publish button – and just like that, my work vanished, because while I was out getting dinner, WordPress logged me out (for some reason I’d assumed that the auto-save feature was also refreshing my session info).

One of the nice things about building my own CMS was that I was free to fix the bugs that bothered me most, and this was a big one for me. I added a feature to my CMS that caught any POST info and showed it on screen, even if the person was logged out. This allowed recovery of the post. I worked on my CMS from 2002-2007 and then abandoned it because I could not keep up with projects like WordPress. Nowadays I force myself to use other people’s open source software, because it is economically rational to do so, but I hate some of the choices they make, and some of the features that they fail to implement.

In the comments, Jacob Davies posts this comment, which I thought was very funny and very on point:

Conversation that has happened more times in my career than I care to mention:

Someone else: “How long of a title shall we allow? 32 characters? 64?”

Me: “FOR THE LOVE OF GOD WHY DO WE NEED TO SET A MAXIMUM LENGTH? IS THIS 1952???”

Someone else: “But what if they put in a really long title and fill up the database?”

Me: “THE VERY NEXT FIELD – THE ‘CONTENTS’ FIELD – IS A FREE-TEXT FIELD WITHOUT A LENGTH CONSTRAINT SO IF THEY WANTED TO FILL THE DATABASE THEY COULD DO IT THERE ANYWAY.”

Someone else: “Won’t it waste space if we allow a variable-length string in the title?”

Me: “OH MY GOD YES A TERRIFYING LOSS OF ABOUT 3 BYTES ON A RECORD THAT IS A MINIMUM OF 1024 BYTES LONG AND OFTEN OVER A MEGABYTE, YOU ARE SO RIGHT.”

Someone else: “Yes but every other system has a length constraint for titles.”

Me: “YES AND I SUPPOSE IF EVERYONE ELSE WAS JUMPING OFF A BRIDGE YOU’D DO IT TOO.”

etc

Computer programmers are subject to some kind of strange mental degeneration in which they rate the potential waste of 0.00001% of the capacity of a modern hard disk as more important than the ability to enter titles longer than 32 characters in length.

If you rely on design lead development for websites, you’d better get the HTML right

Saturday, August 1st, 2009

Rondam Ramblings advocates generating websites from a programming language, rather than having anyone hand code the HTML:

IMHO, no one should ever write any HTML by hand. HTML should be considered exclusively as object code, except for the most simple of quick-and-dirty hacks. The idea that HTML can (or even should) be considered source code is the root of many evils on the Web. The right way to create web pages is by building higher-order abstractions in a programming language (preferably functional ones, but I’m not dogmatic about that).

Nowhere is this clearer than when it comes to forms. Even CSS advocates concede that it’s OK to put form elements in tables. They say it’s because “forms are a kind of tabular data, and that’s what tables are for”, but this just begs the question of how one can tell if a particular set of data is tabular or not. (Apparently, the criterion is: it’s tabular data if it’s completely hopeless to make it not look like crap when layed out with CSS.) But the trouble with forms goes far beyond layout.

This makes design lead development impossible, assuming that the designer does not know the programming language being used. Rondam wants to make a distinction between the source code that one would write in the C language and the object code that a complier would generate from that source code. Since people do not usually argue over the object code that a compiler generates (no one but a compiler writer should care), then (according to Rondam) no one should care what kind of HTML is generated by the software that you create.

Of course, the assertion that HTML should be the object code generated by a compiler falls apart when you are doing design lead development. With design lead development, there is no question that the HTML is the source code that everything else depends upon.

As to why design lead development is important, there are the old arguments: an experience rich design produces good results with users which makes them enjoy using your service, and therefore they come back to use it more.

When your code generates HTML, you rob designers of their ability to innovate

Friday, June 29th, 2007

Some fellow posted a commerical notice to the comp.lang.php newsgroup. For a mere $79 per developer, you can get a PHP framework that does all the same stuff as the free, open-source PHP frameworks. And it has all the same problems, too. In an old post on the Category4 weblog I was ranting about the problems that stem from generating HTML from inside of PHP code. When a PHP framework generates HTML and CSS from inside the PHP code, then programmers end up working on problems that designers could solve much faster. Consider this problem, which the PHP Developers Kit offers as an example of all the wonderful things you can do if you use their $79 framework:

The workhorse of PHP Kit is the container class . It is a box containing other objects, like text, links, paragraphs and even other containers. It is under CSS control so you may create a container using several dozen options, like background color, border style, border color, font size and font color.

Note: the containers above displayed correctly in Microsoft IE when displayed inline (left to right). However, Mozilla Firefox version 1.5.0.4 displayed them left to right but with no width or height except for the width of their borders. When displayed as block (one above the other), Mozilla displayed their size correctly. The display property (inline or block) is not suppose to effect an element’s assigned width and height.

So, um, you really should be able to control these containers from your code, but when you run into a problem, such as different browsers interpreting your CSS differently, you (the programmer) are stuck solving it. The designer, who specializes in CSS, can not solve your CSS problem for you, because they don’t know how to edit the PHP code that generates the CSS. Ideally, all CSS issues should be the domain of your designers, not your programmers, but when all the CSS is controlled by PHP code, then solving this problem is shifted from the designers to the programmers. This leads to workflow problems – in too many web design shops the programmers have too much work to do and the designers too little, and frameworks such as this are to blame. This is bad economics – to the extent that your programmers are paid more than your designers you should be trying to shift work from programmers to designers.

Concentrating all of the important design work into the hands of the programmers is also bad for morale – I’ve worked in shops where the designers had no work to do because they were waiting for the programmers to finish a bit of PHP/CSS template code. It is demeaning and embarrassing for the designers to have no work. I’ve seen them try to make busy work for themselves and they always look a little embarrassed and ashamed. A well-run web design shop will strive to avoid this.

Designers are focused on communicating with other humans, programmers are focused on communicating with machines. One’s users and clients suffer when the actual power to design is taken away from designers and given (even accidentally) to programmers. It is a rare programmer whose insight into user behavior matches that of a highly skilled designer. An intuitive sense of the user experience is the most important skill that a good designer brings to their work. If all the real design power is in the hands of the programmers, one’s websites and web software are likely to be less intuitive than what might have otherwise been achieved. By contrast, a framework that maximizes the power of the designers is a framework that maximizes the chances of a great user experience being achieved.

Again, let me repeat (as I said in that previous post), frameworks like this (I mean the one I’m criticizing) are fine for the individual freelancer who does all their own programming and design work. But these frameworks are harmful to web design firms that work on large sites and who, therefore, need programmers and designers to work together. As soon as you have a division of labor, you need a framework that facilitates workflow, rather than blocks it.

The last time I wrote on this issue (back when I still worked at Category4) a fellow named Matt responded:

While I generally agree on your view of no html in your php, I think there are exceptions. It’s really about choosing what for when and where. For example, form elements being generated by code is acceptable to me. Even as a designer, I would think that looking at a page with a few php/template tags would be better than a page with lots of html; it’s still code. Less control, but as long as the code is doing what you want then there is no worry. And you could always either override/extend the classes generating the code or hack it…. I think that my point is that one could continue to mull over what to use and prematurely optimize resources to the point of getting nothing done.

I’ll say again, if an individual is doing both the programming and the designing, then putting HTML into the PHP might speed things up for them, but as soon as the jobs of programmer and designer are split, then anything that robs designers of their power is likely to lead to work-flow problems. And those cost money, time, morale and sometimes management focus. They also limit the ability of the designers to achieve a great user experience. Matt suggests that form code can be generated by PHP code, but if you do that, you will very likely get cookie-cutter forms. Forms are the single most important area for designers to innovate a great user experience, but the ability of designers to innovate is wiped out if the HTML is generated by PHP code.

As to “you could always either override/extend the classes generating the code or hack it”, only a programmer can do this. Designers can’t do this on their own. If the designers need this done, then they need to wait on the programmer to do it. And then, once again, you end up with a work-flow problem that damages the productivity of the firm. Either the firm’s profits will be reduced or the costs must be past along to the client, driving up what they must pay for the project.

As to “one could continue to mull over what to use and prematurely optimize resources to the point of getting nothing done”, I’m sorry I haven’t stressed this, but the opinions I’m expressing have grown up on me slowly over the last 5 years. In 2002 I started work on a PHP/MySql content management system and I made every mistake that I’m now critical of. Back then, I wrote functions to simplify my forms, such as:

textInput(”author”);

All the HTML was in the function. It’s exactly what I’m now critical of. So what I’m expressing in this post isn’t premature optimization. It’s way-overdue optimization. I’m looking back at the mistakes I’ve made over the last 5 years and I’m trying to express what I’ve learned so others might now avoid making the same mistakes I’ve made.