Testing Typeroom
Posted on 11th April 2008 in Web 2.0 |
In one of the earlier posts about editing a site with Typeroom there was a nice review of functionality but it missed a real-life test case. Now as we have had a really nice option to test it, here is the more specific addition to the previous article.
To test Typeroom, we took the most recent site of Swapnabhumi: The Promised Land that is the site of a film documentary about the stateless urdu-speaking or Bihari community of Bangladesh. The site is W3C standards compliant and passes XHTML Strict 1.1 and CSS Level 3.
In most parts Typeroom did its job well and at the glance everything seemed to be right as the site displayed properly. But then again it didn’t pass validation any more. To be precise, it came up with 171 (!) validation errors.
So here are the flaws in detail:
Regenerated line breaks and tabs
It appears that Typeroom does not respect line breaks/proper tabbing the way expected and blocks of code will appear on one line so that
<div class="strips"> <img title="Anwar Hossain" src="http://tekkie.flashbit.net/wp-admin/files/credits/anwar_hossain.jpg" alt="Anwar Hossain" /> <img title="Shafiur Rahman" src="http://tekkie.flashbit.net/wp-admin/files/credits/shafiur_rahman.jpg" alt="Shafiur Rahman" /></div>
will be converted to
<div class="strips"><img title="Anwar Hossain" src="http://tekkie.flashbit.net/a4315/files/credits/anwar_hossain.jpg" alt="Anwar Hossain" width="66" height="321" /><img title="Shafiur Rahman" src="http://tekkie.flashbit.net/a4315/files/credits/shafiur_rahman.jpg" alt="Shafiur Rahman" width="72" height="321" /></div>
Overhead of relative paths
As you can see above, the path of files/credits/anwar_hossain.jpg has been changed to ../a4315/../a4315/files/credits/anwar_hossain.jpg which is not exactly wrong, as a4315 was the subfolder, but it’s surely unnecessary overhead and it exponentially overwhelming on further revisions. Each revision results in another set of ../a4315/.
This also happens to href attributes:
<a title="Digg" href="http://tekkie.flashbit.net/a4315/#digg"></a>
Open tags of XHTML
Image tags have been left open so Typeroom didn’t consider the doctype. XHTML expects
<img alt="" />.
That is the case for all the elements that do not have closing tags, e.g. meta, link, meta, input or br .
Wrapped comments
Comments like
<!-- Footer -->will be converted to
<div><!-- Footer --></div>
or put into the paragraph which may basically break your site’s layout.
Conclusion
Typeroom is probably highly awaited amongst many website owners and surely it is useful to many. Yet if the developer of a particular static solution has put a lot of effort into standards compliance, Typeroom is not going to respect that effort at this stage and there’s a chance it will break a site.
Looking forward to the first stable.
11 Responses
Thanks for the detailed look-through here, and we really appreciate you turning up these bugs. Surprisingly nobody has reported some of these before (although it’s possible a few of them may have been related to more recent updates).
At this stage, we are really focused on discovering problems that arise with specific use-cases of the system. I think you get the prize for the most critical bugs in one post.
Thanks again and stay tuned for fixes, updates, etc.
This is a damning indictment of Typeroom as a content management system. I could have understood if it was a beta. It is not. Moreover Typeroom charges for the save to server option. Why would you want to use Typeroom which could potentially break your web site and then pay for that privilege too?
I would rather pay a retainer to a web developer to make future edits than use Typeroom and introduce crap code to my site. In the words of Alan Sugar: Ain, you are hired!
Re Reilly: I’m glad you found the post useful.
Re Shafiur: Typeroom is still in the Beta but I fully understand your disappointment.
There is a modern controversy to it all. Even today you can go shopping and pick an axe of industrially manufactured selection of choices. And you can also get an axe made by Scandinavian blacksmiths by hand. Price-wise there’s not much of a difference unless you want an utter cheapie.
I believe that’s the case with web mastering too. There will always be a niche for websmiths.
Yeah you are right. I don’t want to hack my web site to bits with this typeroom. I need a fit for purpose application not a blunt axe which this typeroom surely is.
shafiur - I know you mentioned your friends had a competitive product to TypeRoom Lite at one point, but does this really warrant these slanderous comments on system? The facts on our progress are pretty simple: We are still testing; helpful people like Ain are providing valuable insight and we are actively iterating on the bugs found. Release early, release often.
@Ain. I agree — there will indeed always be a place for the webmaster. Stay tuned for further updates as we work out the kinks in the system. We have a major release coming up with one of the major points being cleanliness of source code. Building an HTML editor that works with the huge variables in existing code is not a small task.
I agree with Reilly – task is extremely complex. Any such initiative should be appreciated and I hope Typeroom eventually releases a good stable product.
And also, regarding marketing, I think you guys should introduce reseller packages, say 10 accounts/sites for a fixed monthly payment introducing a bit of the discount on it.
Interesting point, Ain. We have considered a reseller arrangement and will definitely give this some thought when that time comes.
Bog off Ain - you put a post up about these guys without testing the damn thing. That is what used to be called laziness.
Reilly Sweetland - you can bog off too mate. You didn’t have to engage someone to sort out the mess. Put a health warning on your product - “Warning. May corrupt code and cost you more money in addition to our cut.”
It is in the stage of Beta. It should be rather easy to understand what it means and what are the risks of using any such product.
The product was tested as one can tell off the screenshot of the particular post.
Cut the crap mate. This is the one to use here
http://cssfly.net/
What you code is what you get.
Well, obviously I’m not the one talking crap here.
Your cssfly failed in the very basics. It failed to render JavaScript and proper font for parts of the document not even going into the user interface that has no WYSIWYG in its traditional meaning. It’s not usable by people who don’t know (X)HTML/CSS which is the essence of content management or Typeroom in that matter.
To be honest, it doesn’t stand a comparison with Typeroom, esp. in the light of latest Typeroom developments.