So.

Is it as fun as it used to be?

Archive for the ‘Raconteur™’ Category

How do You Find Banking Services?

How do you find banking services? Google, right? Maybe not.

Back in September my company did a bit of research into just how one might find banking services using web-based searches in Canada. You’d think this wouldn’t be an issue, but it is. And it doesn’t matter if you are looking for online services or branch services. We’ve summarised the problem and its impact in a press release:
60 Million Qualified Leads Untapped by Top Canadian Banks — Leading Canadian banks are missing a $300 million opportunity.

Alex Sirota, of NewPath Consulting had a look, and well, see for yourself what he thinks.

If you want, you can poke about Recursive’s website to see how we’d approach dealing with that problem and several kinds of (surprisingly) similar problems.

Written by hutch

November 4, 2008 at 7:42 pm

Posted in Business, Raconteur™

One of the Web’s Little Mysteries

Why do people think content management is not possible for static websites?

And another related mystery:

Why do people think dynamic site generation is superior to a static website even when the site does not allow for any kind of reader contribution?

And, I suppose if you know me, there’s a third mystery:

So… why on earth do you care Hutchison? Eh?

Well, maybe I’ll start with the last mystery. I do happen to care. For a couple of reasons.

First, it turns out that I’m biased. I’ve been working on a program called Raconteur for the last few years. Until recently I’ve been in denial, unable to admit that it is, in fact, a content management system — well, I’d admit it was like a CMS but would deny it was a CMS. This lead to painful and prematurely technical discussions of what it does, usually by explaining what it doesn’t do. Ever try to describe something by describing what it isn’t? Sigh.

So last week I think, I tried out the phrase “CMS for static websites”. Good grief! Saying that totally eliminated the need for any of that painful and frustrating conversation. What it did do was introduce a couple of questions, but they don’t come up until much later and when do they aren’t asked very hard (so to speak) — the person I’m talking to already knows the answer they just can’t quite believe it.

You know, sometimes I’m appalled how I miss the obvious. The only defence I’ll offer is that there are well over 100 people using Raconteur and not one of them saw this either.

Those questions that get asked later, after a little reflection and googling, lead to the first two mysteries.

The second reason I care about this is because of the unintended disservice done to the clients of those web professionals who hold the views with mysterious origin. I understand holding those views since they contributed to my denial that Raconteur is a CMS. But they are wrong!

A Fact: Raconteur provides a very comprehensive capability for building and maintaining a large static website that anyone would acknowledge is just like a CMS.

A Fact: Raconteur is not the only software that does this, though the club is very very small compared to the total number of CMSs out there. There are thousands upon thousands of commercial and open source CMSs, and some huge but unknown number of ‘home-built’ CMSs. I know of less than six that do what Raconteur does — I expect that there must be more, but I can’t find them, probably because they are overwhelmed by the other CMSs. [UPDATE: I had intended to link to one of our most interesting competitors: Big Medium]

A Fact: contrary to popular belief, static websites don’t get unmanageable at 20-50 pages. Raconteur’s very first live site was around 4000 pages, every last one of them static. Updates to the website can be made in minutes (if you are daring or foolish, you can do it in well less than a minute).

A Fact: static websites are the easiest, cheapest, and fastest way to deploy a website. How often do you get those three things at the same time?

A Fact: — well, this is really an opinion but I’m saying it’s a fact — most ‘dynamic’ websites out there would benefit by being static, and the rest may well benefit by separating the read-write part from the read-only part.

A Recommendation: think very hard about what ‘dynamic’ and ‘static’ mean, be especially alert to logical conclusions being drawn by inadvertently using synonyms of those two words (this is where I think the second mystery originates).

I’ll go into a few more aspects of this later.

This is going to sound like an advertisement, well maybe it is kind of: Raconteur is in production, though currently most people come to it by word-of-mouth, and every one of them knows that they are ‘early adopters’ and what that means. It isn’t really in ‘stealth’ mode, more like a silent presence. The documentation is, at best, sparse. Even so there are more than 100 websites using it. If you want to know more we’d be more than happy to talk to you. We expect to have the documentation completed sometime in August, at which point we’ll be opening Raconteur to a wider audience.

Written by hutch

August 3, 2007 at 11:37 am

Posted in Raconteur™, Ruby, webapps

Using Erubis 2.2.0 with Rails 1.0

I used Merb to build a tool to let me write my new tumblelog ‘So.’. I would likely have used Rails but because Raconteur is still using Rails 1.0, and Rails 1.2 doesn’t seem to want to co-exist with Rails 1.0 on the same machine, I was prevented from doing that. In truth, I wanted to check out Merb anyway, so I took the excuse.

Merb is quite a nice framework, easy to use, and very quick. One of the reasons it is so quick is that it uses Erubis rather than erb. So I thought I’d see if I could get Merb to work with Raconteur.

It didn’t work out of the box. There is of code in rails_helper.rb (which needs to be required in your config/environment.rb file) that:

  • extends ActionView::Base
  • decides that the version of Rails it is working with is before Rails 1.2
  • tries to call the template_requires_setup? method that it thinks is defined in ActionView::Base

The problem is that there is no template_requires_setup? in Rails 1.0

Almost a year ago I wrote a blog entry — Nice Ruby Idiom — that describes a technique that allows you to monkey-patch a missing method into a class while not screwing up the real definition that will appear in some future version. This is precisely the situation I’ve got here.

So…

      instance_method(:template_requires_setup?) rescue def template_requires_setup?(extension)
                                                          false
                                                        end
    

(inserted around line 98 of the file …/erubis-2.2.0/lib/erubis/helpers/rails_helper.rb) does the trick.

It is a bit of a coin toss whether a true or false should be returned… I think I guessed correctly, because it works just fine.

If you are stuck at Rails 1.0 like I am, this might be handy.

Written by hutch

March 24, 2007 at 10:16 am

Posted in Raconteur™, Ruby, webapps

How did your dog food taste?

Recursive Design, my company, introduced version 1.0 of Raconteur in August 2005. We introduced version 2.0 in May of 2006 to a very limited set of customers and with no public discussion I think. There was a good reason for this, but I’ll discuss it in its own posting – when I find the words. We are about to release a major upgrade to Raconteur. This week I think. Maybe next.

At any rate, we’ve had Raconteur available to us for well over a year and a half, and that was getting a little embarrassing. Why? Well, from our web-site:

Raconteur helps you and your team create multiple large, complex websites and keep them current easily.

Raconteur is hosted, on-demand software created to effectively do a single job, that of getting static content on the web. Because its purpose and design are focused Raconteur helps your team focus on the job you want to get done, rather than on the tools you have to work with.

For the record… The the 1.x versions of Raconteur were written in Java. The 2.x versions are written in Ruby, using Rails and xampl. There’s no ActiveRecord used in Raconteur.

And our web-site? Built using Dreamweaver and vim, and updated these days with vim. It was such a pain to update that I hardly bothered. Well, in fact, I always found ‘better’ things to do. Any ‘better’ thing, and anything was ‘better’.

You may have heard the phrase eat your own dog food – well, with the new release and all, maybe it was time for a sample.

I’m not a web designer, I’m a programmer. I do know html/xhtml/xml and CSS reasonably well. And I can be a bit of an idiot sometimes. I figured I’d re-do the Recursive web-site using Raconteur. And I thought I’d check out a couple of new tools at the same time. And this would provide an opportune moment to see what is involved in getting the really nice open source templates designed by Andreas Viklund working with Raconteur.

You may also have heard the phrase don’t bite off more than you can chew which somehow seems especially appropriate here. It turns out that I didn’t, it was a day very well spent.

So what’s the plan? Decide what content to keep from the old site. ‘Port’ one of Andreas’ templates to work with Raconteur. Build a style sheet that duplicates the look of the old site.

In Raconteur, you have to decide how to structure your content. It is very easy to change that decision, but decide you must. Raconteur was originally designed for a lot of pages organised into multiple web-sites. The model is a hierarchy – you have a library of collections of storybooks of stories. And stories are a hierarchy of sections and subsections – the metaphor falls apart a bit here.

A web-site corresponds to a story, though in some circumstances it is easier to think of the storybook as a web-site. In Recursive’s case there is one story and that is the web-site. Unless you do something about it sections are published as a single web-page. Often it is useful to combine subsections to build a single page. The design of the Recursive site does this so the pages of the site correspond to sections and those pages will include content from the sub-sections (like on the news page)

Deciding what content to keep was pretty straight forward. Making that decision and getting it into Raconteur took no more than a hour. We don’t have a big site and Raconteur is quite good at getting new content into place and organised. It would have been quite a lot quicker if I hadn’t changed my mind about how to do it. Raconteur has the ability to represent content to its users as HTML with a WYSIWYG editor or as text using textile (soon markdown). I started off using the WYSIWYG editor, even though I personally do not like it at all – I thought I could cheat and get the transfer done more quickly that way. Well of course I had to make some editorial changes to the content in the process, and I quickly realised that I’d be using that editor until I converted the content to textile, and that I’d really like that when to be now.

Building a Raconteur theme from one of Andreas’ templates was pretty straight forward. It took about 20 minutes, followed by about 45 minutes of tweaking Raconteur to smooth the process a bit. These tweaks are one of the big benefits of me actually using Raconteur for real work – first hand exposure to the rough spots (to be explicit, I change Raconteur’s software when I’m doing jobs like this one).

So in a couple of hours I had our new site running in Andreas’ template and had made some nice little enhancements to Raconteur. Now I had to reproduce our existing design using nothing more than a CSS style sheet. Well I could have changed the HTML template as well, but I didn’t want to do that. I knew this wasn’t really necessary because I had already done this site which is a live Raconteur built site that replicated, pretty much to the pixel, their earlier site (ease of content update was the motivation for doing that site) and that simply must be a nastier task than our site. The Girls Heart Point site took about 16 hours to move and organise the content then redo the design as CSS suitable for a Raconteur theme. I also spent maybe a week tuning Raconteur to make things easier. To be honest, I didn’t have any doubt that I could do the Recursive design with only CSS. What made this interesting was trying to use a couple of tools I had never used before.

CSSEdit 2.0 was released in the last week or so. And Style Master 4.6 was also just released. I wanted to see if these tools were useful in the context of Raconteur. I normally use vim to write HTML and CSS, and in the case of CSS, I’ve been using XyleScope to help for a long time. Personally I think XyleScope is brilliant. It is used to explore how CSS is applied to an html page and does it very well. It is something I would not care to do without. But what about these new tools?

I proceeded to spend the next 10-12 hours playing with these tools. I’m not going to describe this experience here, I’ll post something soon. What I can say is that I’m certainly going to buy Style Master, and I’m 99% sure I’ll be buying CSSEdit as well – they both are CSS style editors but how they do it and where they are particularly useful is different it seems to me.

Anyway, the style sheet used on the Recursive web site is written with Style Master. What I did was to replace the CSS style sheet that is part of the template designed by Andreas bit-by-bit with what the Recursive design requires. I did this with both CSSEdit and Style Master. For this particular task I found Style Master easier to use, and it happens to be the second of the two tools that I used, and that’s really the only reason that I published using the style sheet produced using that tool.

So. That’s that. With all the fooling around it took about 12 or 14 hours to do. And I can change the content easily.

It tastes pretty good.

Written by hutch

November 19, 2006 at 11:50 am

What the Dickens is a ‘Trial Version’ of a Web Application?

What does a trial version of a web application involve? especially when the target user is non-technical and with no conceivable reason to know how to set up a web server?

This is exactly the question we faced with the Raconteur™ Trial version. I don’t know if we answered the question correctly.

So what are some interesting characteristics w.r.t. a trial version of a ‘webapp’? In this case, Raconteur’s case, these include:

* an application that runs on a server rather than the desktop
* one installation is used by many users
* users want to share information
* a login is required
* long running
* a long start-up is not an issue (because it happens very infrequently)
* a heavy footprint is not an issue (because it is amortised over many users)
* installed by an administrator (i.e. an expert and without a GUI).
* uses a web-browser for its user interface

What about a trial version:

* runs on the desktop
* one installation is used by one user
* no sharing of information
* no login
* runs like any other application, the user can quit it at any time — start-up time becomes an issue if it is too long and/or lacks feedback to the user
* installed by the user
* still uses a web-browser for its user interface

We created a trial version of Raconteur that meets what we believe to be the expectations of the user. Were we successful? Yes, it seems so, but is that good enough?

We modified the start up of the application. The server based versions can work as a normal webapp in a Java servelet container (e.g. Tomcat, Jetty) and using an embedded Tomcat server. The trial application runs only as an embedded Tomcat server. The feedback to the user during a start is unintelligible to a normal human being so we had to extend the trial application to use a minimalist Java Swing GUI that provides feedback to the user as it starts up, confirmation that it is running, a quick startup of the default browser pointing to the entry point of Raconteur, and tying the closing of the application to the shutdown of the server. We further modified it to automatically login the user and to eliminate some functionality that isn’t useful in a single user application or that we wanted to restrict in the trial version.

So what happened? Well it actually works, but we are not entirely thrilled with the outcome. The installer for windows and linux is annoying — the installation of Raconteur is really simple and the installer for windows and linux is geared to much more complex installation situations (that’s one way of looking at it anyway) and the OS X version is about as simple as it can get (this we are happy with). The download is huge for such an application, between 14 and 16 MB, depending on how you count, and about 22MB on disk when installed. No user is going to be fooled, this is not your usual desktop application. The biggest flaw is that there is no sensible way to upgrade the trial version to the real version.

Is there an alternative? Well maybe. We could setup a hosted trial version. There would be no installation required, it could be setup quickly (a simple email exchange), we could actually upgrade the user to the commercial version immediately, automatically, and simply — with no loss of work.

Why on earth didn’t we do that in the first place? Faulty feedback maybe. And I suspect that I am somewhat, well, a lot, to blame, the server load scares me (but I’m starting to think that the server load associated with simply the downloading is similar to a hosted trial). We wanted to maximise the privacy of the trial users — currently, it is entirely anonymous, to use the hosted trial we’d have to know a bit about the user, at least a valid email address. Maybe not a bad thing, we certainly would put strict privacy policies in place, but what do users think?

I don’t know.

Now, I don’t get a lot of comments on this weblog (though lots of people email me directly — maybe something is wrong??). It is supposed to be possible to make a comment, maybe this is a good time to start. If you can’t comment will somebody please let me know?

Written by hutch

August 13, 2005 at 6:04 pm

Posted in Java, Raconteur™, webapps

Introducing Raconteur

So. I’ve been busy for the last three months. I feel compelled to tell you why. The trouble is that it’s going to take a while. So I’ll start by talking a little bit about the big one.

For the last nine months or so, Recursive has had a team working on a new product that we are calling Raconteur (with a TM). This has been a full time effort, and I think everyone has done a great job on it.

Raconteur originated with an idea a business partner had some time ago, and who in fact, implemented it (the hard way) in a large site for the Manitoba government. [I can't find the link at the moment -- I'll try to remember to get it tomorrow and update this post with it]. The site is entirely in flash (which is probably why you can’t find it using Google). The idea is to profile various careers in Manitoba to help high-school students decide what to do with their lives. Each profile consists a presentation of a structured interview with someone working at some specific job. It would cover things like routines of the workday, what the work place looked like, what it was like to work there, what educational experience would be helpful, and so on. It would tell the story with text, photos, video and audio recordings. It has been very successful and, I think, a very clever use of internet technology.

At Recursive (my company, where I am one of the owners and where I work as a programmer — just making this perfectly clear) we generalised the idea in very important ways. We started from scratch, and, over the last almost-year we moved from a body of software that had to be extensively customised for each use to what we believe to be something that anybody can use. During this time we’ve implemented a number of sites, some similar to Career Destinations, others radically different (e.g. an actor’s portfolio, and a corporate website, as well as the presentation of information normally distributed as paper documents).

Raconteur is named that for a reason. It is a tool that allows a writer to tell a story on the web. It eliminates as much as possible the barriers to a writer doing this, and most importantly, provides tools that support the writer in the effort. The original use of Raconteur was telling a story of a job to a student. Recent uses have been telling stories about working in Canada to prospective immigrants, and to new arrivals. Telling the story of an actor. Telling the story of a company. Telling the story of a software product.

One particularly public site built using Raconteur, is “Raconteur’s product page”:http://www.raconteur.info/ which describes the product in a bit more detail. You can download a trial version for OS/X, Windows, and Linux from that site.

We think this is an important product — both for Recursive and in general. We have attempted to build a tool where the author can write and update a website without help from anybody else. No, this is not a new idea, but it is a different approach and it does actually work. We have let professional writers and people who write as part of their job use the system, on their own with no instruction, and they have been successful. We’ve had the pleasure of getting a few (professional) writers actually giggling at how easy it was.

We’ve got a bunch of improvements we’d like to make over the next weeks, and we’d like some users to give it a shot and let us know what they think. In fact, personally, I’d appreciate it if people would beat it up and let us know what happened.

But what I’d really like, is if somebody finds it useful.

Written by hutch

August 7, 2005 at 2:30 pm

Follow

Get every new post delivered to your Inbox.