13 comments by 6 or more people

1. Chris May

   Steve Carpenter suggests that this approach could be better employed in an AIR application.

   Well he would, wouldn’t he ;-)

   I suspect, though, that if you’re trying to put a more domain-focused layer in front of sitebuilder’s generic CMS functionality, then starting with what you’ve done so far, and incrementally replacing the iframes with plain-old-HTML forms that call the sitebuilder APIs on submit (sitebuilder.js is your friend here) would be a better bet – your user doesn’t have to leave the context of her website, and you can build on what you’ve already achieved (which is pretty neat, if a terrible hack!) rather than starting afresh.

   If you do go down that route, I’d be interested to find out (a) if there’s stuff we could add to sitebuilder.js to make it more helpful, and (b) whether there’s anything we can do to make this technique more easily applicable by others. I’m constantly surprised (and, to tell the truth, a little disappointed) when I see how few people make use of the sitebuilder APIs to create content, preferring instead to go through complex and error-prone sequences of copy-edit-change-permissions-edit-content every time they make a new module.

   04 Mar 2009, 13:58

2. Robert O'Toole

   She’s just watched a demo video and used the wizard independently. Bingo!

   It’s an example of a custom workflow.

   I’ll follow the advice from Chris and try out the api for creating other custom workflows.

   04 Mar 2009, 14:38

3. Robert O'Toole

   An AIR based approach would allow us to retain some of the Sitebuilder forms AND automate them. That could be good from a training perspective.

   For example, we can simulate the normal Sitebuilder workflow by opening each page in turn and automating data entry, with the user actually watching the data being entered. Perhaps even with an audio or video commentary. Or, rather than filling in the data and clicking the buttons, we can add highlights and instructions that direct the user to enter the right data and click the right buttons (in AIR objects can overlay the browser layer). So the user learns the workflow with assistance, and then hopefully they can do it independently.

   That’s an instance of the ‘cognitive apprentice’ learning design pattern.

   04 Mar 2009, 14:42

4. Robert O'Toole

   Cognitive apprentice design pattern defined

   04 Mar 2009, 14:44

5. Catherine Fenn

   I’m constantly surprised (and, to tell the truth, a little disappointed) when I see how few people make use of the sitebuilder APIs to create content

   Rather nervous of API route with my level of techie knowledge – e-lab does not offer any formal support for use of APIs which could make this a high risk approach for us?

   04 Mar 2009, 16:35

6. Chris May

   elab does not offer any formal support for use of API

   That’s not quite true. We offer the same level of support for our APIs as we do for our UIs – if you find a bug in an API, then we will jump to fix it just as fast as we would for any other bug.

   What we don’t offer, though, is production support for applications written against the API. If you call us and say ‘my app isn’t working, and it was yesterday’, we’ll do what we can to help you work out what the problem is (in the same way that we’d do what we could to help someone who wanted advice on how to use the application generally), but we can’t just debug your app for you.

   We also provide development support – where people are writing their own apps against our APIs, we’re more than happy to offer advice on design and implementation points – in fact we’re keen to get involved wherever possible, as it allows us to catch problems early, and to adapt our own code to better meet real-world requirements.

   Part and parcel of writing your own applications is running and supporting them, so yes, there is a degree of risk involved – just as there’s a degree of risk that people will fail to follow manual procedures when using the ‘vanilla’ system. It might require some investment of effort to minimise the risks of running an application, but then again such an application might result in enough of an efficiency gain to offset that investment. It’s certainly not something that can just be dismissed as ‘too risky’ without some degree of analysis.

   04 Mar 2009, 17:31

7. Mathew Mannion

   Steve C and I briefly discussed the possibility of a custom workflow UI a few months ago, in the context of a lecture management tool. The idea was to create a custom UI, rather than replicating the current Sitebuilder UI, where a lecturer could see a list of all his modules/lectures, and attach things like:

   • A video/audio recording of the lecture
   • Lecture slides (doc, pdf, ps… perhaps auto-converting between them)
   • Other handouts, related reading etc

   The idea being that there would then be several benefits; we’d have a standard format for lecture-specific pages on Sitebuilder being one, meaning that we’d be able to represent the information in a number of different ways, including as part of some kind of academia-related portal, and (more importantly) it would allow a very focussed tool to be presented to users when they want to put (very useful) content on the website. I’m constantly worried that users are ‘put off’ putting content onto Sitebuilder because the UI is very much one for a generic CMS – we have to balance this against the extra effort we’d have to put into creating and maintaining these extra UIs.

   Extending this logically past lectures, one could imagine a whole host of template sites, each with their own specialised UI. Whether AIR is the most suitable tool for this is another matter – if we’re simply using it as a way to display forms to the user without using any of the cool AIR features (and sliding transitions does NOT count as an AIR feature…) then a far more reliable way to represent this would be a web application, which has far fewer issues with authentication, updating etc.

   08 Mar 2009, 11:55

8. Robert O'Toole

   because the UI is very much one for a generic CMS

   Yes, i do find that. Also, using Sitebuilder requires that the user has a ‘cognitive model’ (pages, properties, tree etc) that is related to but quite different from their ‘cognitive model’ behind their goals in using Sitebuilder. Or in other words, they are working with the teaching/learning/research workflow (which is hard in itself) and then trying to abstract away from that to the Sitebuilder workflow.

   09 Mar 2009, 09:13

9. Robert O'Toole

   I’m using AIR because:

   1. it allows me to do cross-domain scripting (https://sitebuilder and http://www2);
   2. I want to have a separate visual layer that can be superimposed over the browser – so for example, I can fade out all parts of the browser except for one small circle, to highlight a part of the page very clearly.

   09 Mar 2009, 09:16

10. Richard Cunningham

    Chris, is it possible that people are not aware that there is an API?

    I can’t see a route to it from http://www2.warwick.ac.uk/services/its/servicessupport/web/sitebuilder2/ or the FAQ page it is listed under. There is no go link.

    I didn’t look for something like this before, because I assumed that there wouldn’t be one.

    09 Mar 2009, 13:33

11. Chris May

    It’s certainly possible that this could be the problem.

    We’ve shied away from advertising it too strongly in the past on the FAQs pages because, I think, API users make up a tiny tiny proportion of our overall users. We don’t want people browsing the FAQ pages to end up with the impression that you have to know how to drive an API in order to use Sitebuilder!

    The API has had mentions on both the Sitebuilder and the Flash-dev forums recently (we ran a half-day introductory training session a couple of months ago) and if you put ‘API’ into the “search these FAQs” box it comes up as the first result. But maybe it wouldn’t hurt to have an explicit link down at the bottom of the FAQs page

    09 Mar 2009, 15:35

12. Katharine Widdows

    Please can I ask a silly question?
    What is an API?

    16 Mar 2009, 14:06

13. Robert O'Toole

    Hi Katharine

    Apologies for the acronymn. It means Application Programming Interface, meaning a set of codes that can be used by one program to make things happen in another. For example, it is possible to write a program that reads from a list of students, and gets Sitebuilder (through the API) to create a web page for each student.

    Robert

    16 Mar 2009, 14:26