Skip to main content

Posts

Showing posts from February, 2007

Digging deeper into CMS requirements (#4: Costs)

This is the fourth post about digging deeper into content management requirements. See also Requirement Overview Technical Requirements Management Requirements End-user Requirements This is perhaps the most important factor for WCMS buyers. The total cost of an information system is easily displaced as buyers have a tendency to ignore the total lifecycle of the software. A CIO in a small company could explain that she spends zero on web content management since she does it all by herself, but the number of hours she spends updating the web content each week might amount to a significant expense relative to the size of the company. A WCMS has costs upon acquisition. The software is bought, and additional modules or plug-ins will likely add to the price. It must be tested, deployed and tweaked by developers to fit the company's environment. A web design must be applied to the templates. Users must be instructed on how to use the system. Older content must be imported. There are

Worthless Practices (IBM's list)

I just saw via InfoQ that IBM maintains a list of Java EE best practices. Now I've never really been good with bile, but there is just so many things wrong with this list on so many levels. Just listen to the title: "IBM WebSphere Developer Technical Journal: The top Java EE best practices". A bit of paradoxial, isn't it? Let's take a quick look through the list and comment on each point: 1. Always use MVC. Yeah, right. Always use MVC. Remember to design a rigid 3-tier architecture upfront no matter what sort of application you are going to build. Use Struts, right? Right. 2. Don't reinvent the wheel. Well, duh. Struts, right? Right. 3. Apply automated unit tests and test harnesses at every layer. I'd actually support this one if I could append "if possible". 4. Develop to the specifications, not the application server. Well that certainly was a good tooting from the wrong horn, coming from the deranged nit-wits that gave us WSAS and

Digging deeper into CMS requirements (#3: End-user Requirements)

This is the third post about digging deeper into content management requirements. See also Requirement Overview Technical Requirements Management Requirements Today I'm gonna run through two categories of requirements. They both have to do with how the CMS is portrayed towards the end-user, through translation and delivery. Globalization International companies need multilingual web-sites [Huang, 2001] with internationalization and localization features . Internationalization This is the concept of having country and language-specific content, essentially having the main content of the web-site translated to one or more languages [Iverson, 2002]. Translation of a WCMS can be divided into two parts. The most important one is how the content itself can be translated by the content managers. The other aspect is the language of the WCMS itself regarding internal interfaces for administration and management. Localization This refers to visual effects based on the visitor'

Finally we're starting to get some real Web 2.0 stuff!

Can't belive I didn't notice Yahoo! Pipes earlier. That site/concept could pretty quickly turn into one of the biggest things in our Web 2.0 craze.. Here, I made one that joins my InfoQ feed and the TSS feed: My first pipe . But do I think it's really useful for anything? Nah, don't think so. I'll settle for my bloglines for the time being.
This tuesday I'm going to do a workshop on wiki for some people in management/business development department. We've been smart enough to choose Confluence for our internal wiki, and its use has been growing steadily ever since last summer, bout the same time as I joined the company. Over this time I've managed to earn the rep of a wiki-evangelist within the company. This is probably I've taken the time to learn the in's and out's of Confluence content formatting, making pretty layouts with columns and tables, galleries, RSS-feeds, and intranet blogging. Some people think I spend too much time fiddling around with it (see for instance the screenshot of my personal space page), but I think it's fun and interesting to try out. I'm not doing it to evangelize the whole company into going crazy on wiki-usage, I just use the wiki to cover my own butt mostly. If I didn't write things down in the wiki, I'd very quickly fall into the state of corporate

Mixing Iron and Clay: Implementing CMS and Portal as one product

For the last few weeks I've had the joy of working with a portal solution that also provides excellent CMS features. More often than not, portal meets CMS by being a Portal with some junky editor functionality inside , but there are also some CMS'es that feature bits'n'pieces of functionality like portlets, widgets and plugins. The portal I've been working seems to strike in the middle. It has the richest CMS interface I've come across in a portal product (content structure, versioning, editing all neatly packed into a comfy filthy fat applet client that actually works), and every bit of content is actually an instance of a portlet by its own right (how they've managed to keep the performance so high is quite impressive, and a mystery to me). This means that not only can I choose each piece of content from a large variety of portlet packages, but I can also transcend content between different states , which is a very handy portlet feature. However, there is

So you want to get rid of Use Cases?

I'm going to do a lightning talk on this topic at tomorrow's XP-meetup , so if any of you devoted readers are attending you might get away with reading this blog-post. Spend the five minutes going downstairs for a pint, and bring me one while you're at it, please. I was once in a meeting participated by a team of developers, requirement managers, test managers and project managers. The topic of discussion were how requirement changes should be handled. The original requirements were described mostly in the form of use-case documents. The problem, and the reason for the meeting, was that the implementation was failing to follow the stuff specified in the use-cases. The round went around the table with each and every member pledging to read the use-cases more carefully, and the requirement manager promised to clearly highlight changes and references in the documents. When the turn came around to me I said something along the lines of: I have read the use-cases already. I'