© 2009 chilts.org | Created with LollySite
Privacy Policy | Terms of Use | Original Design: Free CSS Templates.
Found 10 entries.
It is well known that the large majority of HTML pages out there are invalid HTML, use custom tags and have layout information mixed in with semantic information.
The real surprise though is that a lot of these pages have been crafted by professional designers and developers over the years. People who are actually being paid to create these things. Properly you might think. But no, not even close.
So if the people who are being paid to create the HTML can't create it correctly, what hope does that leave someone who isn't trained in it at all?
The answer is (of course) none. No hope whatsoever. Even assuming they have had minimal training in HTML, it just isn't enough.
But why is that whenever we have a new client and they say "And we want a WYSIWYG to be able to edit everything" we say without hesitation "Of course". In my view, the customer is not always right and it is wrong to give them that option.
I'm of the opinion that WYSIWYG editors are bad for clients to use especially because most editors generate HTML. The client moves on from wanting some minor formatting buttons and quickly on to "we want to edit all the HTML in the world directly".
This just causes problems. Not just immediate ones but long term ones too.
Firstly the client starts creating weird and wonderful effects (as shown today on Contented). Soon enough they start creating invalid, inconsistent and badly formatted HTML. It gets even worse when <font>, color="#bbb" and unclosed tags start appearing. Don't even get me started about embedding JavaScript in tags to popup a video window - it's not nice and it ain't pretty.
(Aside: I tried to explain unobtrusive JavaScript to a client once but I'm not sure I was explaining it on the right level even if there is such a level as a correct one.)
Even ignoring the actual edited HTML it also leaves the rest of the nicely groomed and well maintained site at the whim of someone who knows nothing about the web let alone the subtleties of HTML.
This practice is incorrect and this function should never be given to the client. It's in their best interests not to be able edit HTML and this practice should be changed.
Instead, clients should be given one of two options:
1) a a semantic markup language they can use which is relevant to their site. Anything to do with styles, layout and formatting is no concern of theirs. Instead they should know what a heading is, a paragraph, some emphasised text and what a link looks like. If you want to give them higher abstractions, how about an external link or a popup one. What about an embedded picture from a local store or from Flickr, or even a YouTube video. This is easy from your point of view and simpler from theirs (no more HTML cheat sheets for the editors).
2) or give them proper editing screens in the CMS which lets them edit only the content of the site. Whenever something should look different it should be because it is different not because someone says it should look different. The Content Management System should be for editing content and content only. It is not a Content, layout, formatting and stylesheet Management System. (And no, I don't believe they should be able to move blocks around in the CMS either but that's a different story.)
Let me give you an example of what happens now and what really should be happening. Let's say you have blog entries on the site each of which has a headline but depending on what type of blog entry it is (technical, opinion, guest), the sub-heading should look slightly different.
What happens now is the following. The editor says to himself:
"Hmm, this blog entry is an opinion piece so the subheading should be blue and bold, but this one is a newsflash, so the subheading should be red and flashing!"
This is bad. Bad, bad, bad.
To fix this you need to do some research on how many different types of blog entry there are. It's not so hard really.
You just quiz the client on how many blog entry types there are and arrange for the appropriate tickboxes, drop-downs or select boxes to appear in the CMS. This way the styles for every blog entry type are correct, consistent and don't look terrible. Furthermore, they are semantically defined rather than syntactically defined. (You have heard of the semantic web, haven't you?)
And finally, if those advantages weren't enough this last one really drums it home. When the site's design is changed in 2 or 3 years time and the blog entries have to look consistent with the new design, showing the sub-headings with the new correct styling is trivial.
Try doing that when your subheading has invalid, unknown and inconsistent HTML in it. Furthermore, if you think sub-headings are a problem, just wait until you get onto the blog entry itself, spotted and pitmarked with nasty HTML all over the place.
All I can say is, good luck to you or the poor person who has taken over on the project. That's going to one beast to untangle.
Labels: web, html, cms, planet-geek, planet-catalyst, content
Inserted: 2008-04-15 22:08 (2 years, 3 months ago)
For years, it has been said that Free and Open Source Software is created when someone has an itch. That may be true, but I'd like to present a view after that initial itch has been scratched.
I'll start this entry as a question and answer session.
Question: How many times have you created a piece of software - one which scratched that initial itch - but once the initial problem had been solved you stopped working on it?
Answer: Loads. Not one or two, or even five or six. I'd say upwards of 10, maybe even 15 or 20. I even have old repositories to prove it.
Question: Why is it that once the problem is solved, work is almost immediately dropped?
Answer: Mainly it's because the challenge of fixing whatever the itch was then goes away and the itch dies down. Also because the interesting thing you wanted to solve is no longer interesting. It's sad to say that because of this no-one ever sees the beautiful code you stayed up for three or four nights crafting.
Question: So how does a project move from the initial itch stage into being a full blown development project.
Answer: Imagination.
And there you have it, it's that simple. Imagination is the driving force behind any large project. Without it, the project stalls and nothing else gets done. As proof, let me give you a few examples:
Hence, from the above musings, the internet, the World Wide Web, Wikipedia, Linux and ODF all came into being. Though they might have had different thinking at the time, I suspect each of these projects stemmed from someone's first itch but only carried on because of their imagination.
Imagination is important because otherwise projects would just stop. If the itch has been scratched, even if the software is also released as Open Source, no new development will happen since there is nothing taking it anywhere. There is nowhere left to take it - it has fulfilled its destiny (think grep).
The only thing that can take that project forward is imagination. You need to be able to figure out what the next step is, where you want to go and where you want to be. Even if the original need has been fulfilled, imagination means there is always something to do next.
I was thinking about all of this on the bus on the way home from work. I'd just had a conversation in which the other person stated that various government organisations had listed Drupal and Plone as their preferred CMSs. I had been pimping Zaapt as something that is ready to be used in a production site. Granted, those other CMSs have a few more features than Zaapt - and I can point to a few reasons why - but it just seemed that because these other two were the preferred CMSs that Zaapt wouldn't get a look-in. Or indeed any other CMS for that matter.
So that's why I'm glad that I have imagination. There have been many times recently that I have imagined when Zaapt will be used on big projects, hell even government ones. And the reason is because I always wonder what I can implement on Zaapt next (e.g. the list of features needed for v0.2 even though v0.1 is only just feature complete).
At first, you'd wonder if that closed thinking would put me off. Certainly, I'm disappointed but it doesn't worry me, besides, I like a challenge. Zaapt has already scratched my initial itch and fulfils all of the initial problems I set out to solve - in fact, the itch disappeared a long time ago.
But yet somehow Zaapt is now one of only a handful of projects that I have kept developing consistently over the years. The main reason for this is because I have an imagination. There are so many places to go with it, things to do, places to see, all fulfilled by the usual constraints - time and resources - but gladly not constrained by imagination.
And I imagine that Zaapt will eventually be the biggest CMS built with Perl[1], which was always one of my original intentions :-)
[1] Yes, I know that is a tall order and maybe that's not just imagination but a dream - still, we need that too.
Labels: perl, zaapt, drupal, cms, planet-geek, planet-catalyst, plone
Inserted: 2008-01-11 20:25 (2 years, 6 months ago)
A few days ago, Zaapt became one year old. But the best is yet to come.
It's been a great week for Zaapt this week. Not only has it passed it's first birthday (born on first check-in) it's also had a lot of development done on it. The models were improved in Sep/Oct and this month it's been the controller side of things. The views didn't need much change but maybe a minor tweak here or there.
I mentioned the other week that I am now using the issue list on my Google Code Project Homepage. At this very moment I can tell you that there are six issues I have to do before I release v0.1 - which will be an amazing achievement. It will also signify the first release which I will be happy for other people to start using - before now it was still in a little flux.
As 2007 finishes up, I look back on the number of hours I've put into Zaapt and see that it's all been worthwhile. I have spent a hell of a lot of hours on it but to now have a CMS written in Perl and using PostgeSQL as it's main store is just great. It was always an ambition of mine to have that combination and Release v0.1 will realise that (note if you Google for cms, perl and postgres, Zaapt is in the top 10 hits and has been since March).
As Nigel a friend of mine said to me recently, "We just shake you and a site falls out" - which just proves how easy it is to create a Zaapt site.
So 2008 will be a belter of a year for Zaapt. I'm aiming to get it into Debian with the help of Francois Marier so after the v0.1 release, I'll sit down with him and figure out what I should do before we put it in - he doesn't know this yet :-)
Finally, just to give you a glimpse of how interesting Zaapt will be next year, here's a quote from one of my current open issues:
This issue also implements an idea I've had for a while in which models can also be mash-ups of other models. In this case, one model is referencing another. In another case, who's to say that a model might not just link together a blog.entry, a gallery.picture and a map.location.
Wouldn't that be oarsum - "CMS mash-ups".
Labels: perl, zaapt, cms, planet-geek, planet-catalyst, postgres
Inserted: 2007-12-24 17:32 (2 years, 7 months ago)
I decided to submit Zaapt, my CMS, to Ohloh and here's the results.
The page for Zaapt on Ohloh shows a few interesting things about Zaapt the CMS.
Firstly, they show that I have done 3,039 lines of code, by hook or by crook (of course, they don't know that I have Perl generating at least a thousand or so more than that). I thought I'd done more than that, but hey, at least it's succinct. As it stands, they estimate that, at something less than 1 Person Year averaging $55,000USD a year then the Zaapt code base is worth a whopping $34,834USD.
It turns out that Zaapt is 7 months old today so I reckon I've done well to get it where it is now. Though I don't believe the calculations Ohloh generates I guess it's just an indication of what's been happening on the project.
What's more interesting is the code analysis page. I always think I comment code about right - who doesn't? - so I might have to compare (my 12.1%) with other projects and see where it fits in. I suspect that the weird mix of HTML/Perl in Mason might throw the 'Languages' used off a bit. Certainly there is more than 3% HTML and much less than 73% Perl so I reckon all Mason files are treated as solely Perl.
In the Contributors section (yes, I'm the only one), the other feature I find quite useful is my personal metrics for Zaapt. It's nice to see how many commits and lines I'm changing (per language and) overall on a monthly basis.
It's just a bit of fun so I'm not too bothered what it says, but it is interesting. I'd also like to know what adding the KiwiWriters repository would make all these figures. Unfortunately that SVN isn't public so I can't. Maybe I'd hit $50,000USD for half a year's very part-time work.
Not bad eh!
Labels: zaapt, cms, planet-geek, planet-catalyst, ohloh
Inserted: 2007-07-20 00:03 (3 years ago)
Both are well underway. Zaapt is progressing and Project X is almost ready for launch.
Over the past few weeks, I've spent a lot of time working on Zaapt and ProjectX. Zaapt is a CMS which provides content management for small to medium sized sites, but it doesn't force the site structure in which you have to work. The reason for this is explained in a previous article Zaapt, a new CMS.
The best part about Zaapt CMS though is instead of developing it and then developing a site, I have had a fairly big site to develop alongside it - Project X. This means that straight away I can analyse the CMS skeleton I have put in place and verify that it actually works the way I want it too. I also have people playing with it too, which is great to track down bugs and get them fixed early (thanks guys).
The current high level of achievement hit home to me a couple of days ago when I realised that my design was on the right track. Up until that point, I had been adding generic content types that almost any site can use (blogs, news, managed pages, forums, etc) but I then had to add a type which was specific to the site. For example, the Account information is generic across all sites - but this site required a Profile for each user.
Now you might say profile is generic, but it's not. Yes, the idea of a Profile is generic, but the contents aren't. For example, if you've just joined a Photography site, you may want to say who your favourite photographers are. If you've joined a games site, they won't care about your favourite photographer, but will care about the game you've played the most.
From a Perl point of view when I added the generic type, instead of using the Zaapt namespace, I used the ProjectX namespace. It inherited the various things from Zaapt it needed and the model worked fine. There is also generic database patch scripts which live in the project instead of Zaapt, and finally, the Mason pages live under the project's htdocs instead of Zaapt's Mason hierarchy.
So there was three things it seemed I had designed correctly in the beginning with a view to generic and specific types and all of them worked out perfectly. It made me very happy.
You'll be able to get a feel of how Zaapt is progressing soon when ProjectX is released. Then you'll also be able to see the fruits of labour from a great group of people.
Unfortunately I can't link to it yet (which is okay) but will do really really soon :-)
Inserted: 2007-01-27 12:23 (3 years, 6 months ago)
I've been head down in writing my new CMS and the new site for ProjectX...just wait and see, it's going to be great.
After a number of weeks with my head in the laptop (like your head being in a book, but slightly different), I've made great strides in the functionality of the new CMS and the first site which will use it. There are page types for content managed pages, blogs (50% done), news, FAQs, Forums (90% done) and accounts (25% done).
For those wanting a sneak peak of the CMS, take a look at Zaapt Home and \[p]{Zaapt Project Home|http://code.google.com/p/zaapt/}.
As for ProjectX, I have 2 more things to implement before we can go live. I want to add some Profile information for each account and then I can get started on a few added extras specific to the site itself.
I'm really, really dieing to tell you all about it but I can't yet. Once we do an official launch, then I'll be able to write something here. Let's just say I'm excited and I think the rest of the group are too.
Inserted: 2007-01-14 21:12 (3 years, 6 months ago)
As stated in an earlier post, my ambitions for a simple but powerful CMS is progressing well.
I have added various content including Accounts (partial), Content Pages, FAQs and Blogs (partial). Planned content types to be added soon includes News, Forums, Links and Menus. I'm sure others will be added as it all progresses. Also, there is provision for sites to add their own content types on top of the boxed content types.
Progress is going well though of course it is still in the early stages of development. Even though I am taking the traditional route at the moment, there are plans to add shiny new Ajax to make things even nicer.
Finally, the project code can be found at Google Code under the \[p]{Zaapt|http://code.google.com/p/zaapt/} project. See the \[p]{Zaapt|http://kapiti.geek.nz/software/zaapt.html} home page for the commit, issue and discuss groups...though these are quiet at the moment that's fine by me while I carry on.
Inserted: 2007-01-04 01:44 (3 years, 6 months ago)
Zaapt is a small and fast new CMS I am part way through writing.
For a while now I have toyed with a few different CMS tools. To be honest, there are plenty more I haven't played with but of the ones I have, I haven't been very impressed.
Now this post and my new design of a CMS don't have anything to do with the quality of those other CMS's. Quite the contrary and let's face it, the quality is very high. It has more to do with the perspective I am coming from in using and maintaining a CMS. For example, most CMS's are designed to be installed by users who want a website and who don't want to get their hands very dirty with the backend. What this also means is that configuration, design (both HTML and CSS) and plugins are all managed via the web interface.
I don't like this approach.
More importantly however, in a lot (a hell of a lot) of these cases, the people who are managing the CMS don't really know what they're doing. The reason they need this web interface to manage the CMS is because they don't have the expertise to get in via the backend. Unfortunately, this usually means they don't have the expertise for these front-end interfaces either.
I, however, like to get my hands dirty. I certainly don't like web interfaces for this type of configuration - instead I prefer, like and enjoy the command line. I also like source control systems and scripts.
Now I will describe a short lifecycle of using one of the current CMSs.
Let say that a small company (an individual, a friend, a charity, a relation, or whatever) comes to you and asks you for a small website in which they can manage the content all by themselves - a CMS if you will. This approach would work well since they pay you once for installation, you leave them be and they can do the rest themselves! The story then goes that they also leave you alone and you can forget about the whole thing because it just works. It goes both ways.
Except it doesn't quite work like that. Instead this is what really happens.
You tell them that the install went well and they can now start adding content.
But then something happens and it's not so great.
Within one day they've tried changing the layout of the front page, munging the CSS to make the site green instead of blue, installed a forum plugin which doesn't quite work how they want it to along with an FAQ plugin which doesn't work at all. Now it gives unknown errors in the browser window, the CMS's log and the page looks 'a bit funny'. What they are left with is a broken installation, for which they have absolutely no idea how to fix it up and instead have to pay you to correct it for them.
But you don't want to do it since you only ever wanted to install it and be done with it - you didn't even like it in the first place and now you like it even less.
There goes that it just works approach.
That was just a simple example. If the website originally requires an install which has new content types, different design, major template changes or pages with alternative layouts, then you're in even deeper.
So alot of these CMS's are big and can do a lot out of the box. But they're also hairy. Big and hairy don't make nice, easy or beautiful in my book. It can make functional and working but for how long? This is especially true if you vary much from the standard install.
Changing the layout HTML means anguish. Changing the main CSS means pain or starting afresh. Changing the odd page to be different means dead brain cells. Adding functionality means an excercise in self inflicted eye poking.
Also, did I mention that you have to do all of this via a web interface.
So what's the solution?
Well, my approach to this problem is from a programmer perspective. Read on...
If you have to hire a programmer to install, configure and/or fix a system for you, then why not make it as nice for the programmer to do these things pertinent to them as you are trying to make the interface nice for the content manager to manage the content.
This means no fancy web interface for system configuration - the content manager knows nothing of the system. No fancy web interface for changing the layout HTML - what the hell are the content people changing the layout for anyway! No fancy web interface to change the CSS - again, they are content people, not designers. And no fancy web interface to install plugins - what the hell are they ... you get the picture.
You do still have a fancy web interface for managing the content however. This makes sense :-) Adding a new news item, changing the content of a page, editing a blog entry, auditing of comments, addition of links and quotes or a new FAQ entry. These are all content management tasks and that, essentially, is what the website needs to provide and what the content managers need from the website.
So this Programmer perspective CMS, what's in it for you as a programmer?
You get lovely scripts to play with. You get package install scripts which are automatic. You get database patch scripts which just work. You do have to do some minor configuration but convention has given you almost everything you need already. And finally, you get some default HTML templates for the content itself but you get nothing (I repeat nothing) for the site itself. No layouts, no design and certainly no HTML. You also don't get any CSS. At all.
And if you're expecting any more than this, then you're out of luck. You get a couple of examply sites to show what you can do and how you can do it, but that's it. Most of the time, the look and feel of each website is so different, that starting with a default look (added to the fact that it's so hard to change) means that they all end up looking the same - which is no use really. By not giving you anything at all, but instead giving you the power to do anything you want, then you can let you mind free.
You do have to do some other work to setup the webserver and suchlike but it isn't any more work than other CMSs out there.
You have full control over everything and in a way that is easier and more straightforward to you as a programmer. The reason why you understand it better is because you understand how it fits together at the back-end, instead of the more usual black box that you have to control via the web front end. You can also configure it faster since you are within the realm you understand. Not that you'd have to do much configuration anyway. It's a far cry from some slow-ass GUI in which ... [example snipped since it ranted on for too long].
So that's about it. I know I haven't talked technical, but then that's not what a CMS is about. Implementation details can come later.
To summarise, it will be a CMS for programmers which is content managed by users, rather than a CMS for users which is hated by programmers.
At least, that's what I'm aiming for. Wish me luck :-)
Inserted: 2006-12-16 11:12 (3 years, 7 months ago)
After a fair bit of work over the past month or so (since when kapiti.geek.nz started), my new CMS is starting to take shape.
Today, I finished off adding the content managed pages as seen in the (sparsely populated) Software section.
The best thing about the new Content type though, is that it fulfilled all of the criteria I want for all the new content types which I will be adding to it. So far, the Blog type (which is used for /random) is mostly there but doesn't quite fit the abstraction I want it to. The DB class is fine, but the display pages are lacking since I'd written them for this site before I wrote them for the CMS.
On the other hand, I wrote all of the display code for the Content type before I wrote anything for this site and it turned out well. Out of the box, the CMS will support 'text', 'code' and 'html' types - weird I know but it proves the concept. Despite this, I assign my pages a content type of Phliky then, in kapiti.geek.nz, I override the display of that particular type and don't have another jot of work to do :-)
Inadvertently, though I guess I am inclined that way, this new CMS pretty much follows the MVC pattern. I'm not always sure that this is necessary but once a project starts getting big, then it's the best way to go and hopefully this one will get bigger.
As an example, the database interface code is written in Perl modules. The admin interface (which could be termed the controller) is written in Perl/Mason and is a part of the CMS code. The View pages have default versions in the CMS code, but can be overridden with the website pages, which is the technique I used to display a phliky type in the content pages. This approach seems to be the way it turned out and the way it will continue to move forward.
Oh and by the way, I haven't yet worked out a name for it. At the moment, the working title is Fli since it is a play on Fly and hopefully should be really fast. If anyone has any suggestions, let me know.
Labels: perl, mason, cms, mvc, kapiti-geek-nz
Inserted: 2006-08-13 01:20 (3 years, 11 months ago)
After a short while playing with kapiti.geek.nz, I've pretty much done all the admin interface now.
You might have noticed over the week or so, I have done two main things: (1) I broke the posting of comments on the blog entries, and (2) I added a random quote to the top right.
Well, I've fixed the first and am now using the new admin interface to manipulate the blog and its entries. I also have an admin section for the quotes and for the (RSN) content managed pages.
I'm doing it all in such a way that if I want to re-use all these modules in a future project, I can and do so quite easily. This site is a DAMP site (of course), and after a while playing with different websites, I know what I want, how to do it and most of all, be consistent in my approach. This way future additions are easier.
At first, I wanted the administration to allow many users, with different roles and access permissions, but there are many \[p]{CMS tools|http://www.cmsmatrix.org/} out there which do all this - and they are huge, both in function and form.
My plan is to make something a lot smaller and allow any user to change anything. This means there will be the abilty for many people to log in, but no access rights or roles need to be assumed - everyone has the power to do anything. It will be ideal for personal sites and for small to medium businesses. Even so, I have ideas about how it could expand to fill in all these things, but I'm trying to repell them since that will ruin the overall plan - to keep it small.
Eventually, I will get everything together and release it on this page, but not until I have a few different content types and a consistent approach. There are other things on the way but I won't promise too much for the future.
Look out though for some recipe pages over the next week or so :-)
Labels: cms, kapiti-geek-nz, damp
Inserted: 2006-08-12 01:31 (3 years, 11 months ago)
© 2009 chilts.org | Created with LollySite
Privacy Policy | Terms of Use | Original Design: Free CSS Templates.