On Sat, 9 Apr 2005, Daniel R. Rehak wrote:
> Take a look at: http://demo.cordraregistry.net/
> This is an early UI example done to solicit requirements, show users, etc.
> (IGNORE the HcE-R label, its for demo purposes only and I don't have
> permission to show the name of the actual registry).
>
> The search returns a static page, but it illustrates no fragmentation in the
> simple search interface, and limited ability to slice the results. There is
> still lots of work to do here to understand both how users might slice
> results, and to build the structures and interfaces so they can properly do
> it.
Dan,
I'm not sure if you posted this stuff here because you wanted comments...
but, in case it is useful, here are a few semi-random thoughts from me.
I appreciate that your example interface is a work in progress and that
therefore some of this may be inappropriate. If so, apologies.
> It looks like Google because that's what users expect.
There are some differences though...
Google doesn't badge itself as a 'registry' - a term which would, I
assume, leave most real end-users scratching their heads? Now, depending
on who the end-users of this 'registry' are intended to be, this may not
matter - since the intended users may understand completely what a
registry is in this context? Though, even from my perspective, I'm
confused about why this is called a registry rather than a search engine?
The point is that the simplicity of Google is not just in the way the
interface is presented (the HTML, etc.) - the whole concept is very simple
and intuitive. Even people who are new to the Web very quickly understand
what it is that Google does for them.
As an aside, I wonder if we have similar problems with the word
'repository'? We all use the word repository in a semi-technical sense
amoungst ourselves - though, as I hinted in my response to Debbie, we can
still argue about whether a 'repository of metadata records' is really
just a 'catalogue'?! But somehow that term also leaks out into our
conversations with end-users. So we go and talk to our academics or
computing service staff about setting up a 'institutional repository' when
the words they really want to hear are 'content management system' or even
just 'database'. Again, I wonder if some of them leave scratching their
heads and wondering what on earth we're on about. I assume that this was
the thrust behind the recent request for clarification about the various
different names for repository-like objects that we now use? But
anyway, I digress...
On a related note, Google doesn't give me links labelled 'metadata'! And
it doesn't give me many obvious links to XML. And why should it, since,
with the exception of RSS, there is no useful use that I can make of XML
links in my browser. By and large, links to XML are for machines, and
should therefore be encoded in appropriate (invisible) ways (as per the
recent discussion about using the XHTML <link> tag).
On this last point, I think we need to think thru what we are expecting
end-users to do with this kind of content (learning objects) when they
discover it using their Web browser. Speaking personally, I can't do
anything useful with an IMS Content Package if I get one onto my virtual
desktop. I have no tools for dealing with them on my desktop - and that's
where the objects will end up if I search for them using my browser.
(Well, I suppose I can just treat them like any other ZIP file and ignore
the embedded metadata they contain - but this doesn't seem ideal?) So, I
wonder if learning object search engines that offer a Web browser
interface should handle the unpacking of the learning object on behalf of
the end-user - in order to deliver the (more useful?) component parts
directly? Yet I assume that this is non-trivial to do - since it will
necessarily have to be done outside of the context of a true 'learning
management system' (LMS)?
This is why we want repositories to support search protocols like SRW of
course... because then, our server-based LMS (Blackboard, WebCT or
whatever) can do the search on our behalf, bringing back the object into
the LMS, where it can be dealt with appropriately.
The alternative model is to move the LMS onto the desktop where it can be
closely integrated alongside the end-user's browser. That way, when I
discover a learning object using Google, your 'registry' Web interface or
some other Web-based search tool, I can make use of it directly on my
desktop, within my personal LMS. The desktop LMS would handle my
interaction with the learning object - but the tracking information and so
on would be stored server-side. Exactly how our desktop-based email
clients use the IMAP protocol. OK, a Web-based email client is useful
occasionally - but not many people would want to use one all the time!?
Perhaps what we really need is ILOAP (Interactive Learning Object Access
Protocol)? :-) OK, that's not a serious suggestion, since the
complexities of accessing a learning object from a repository, presenting
it to the end-user and then tracking progress to a SRS or whatever are
vastly more complex than accessing an email message and updating a few
flags.
> The latter, I think merit more developments, as we are doing here. I think
> also this is not about Google vs. Cordra.. but rather how Cordra would also
> provide for a google like view.
>
> ...
>
> It looks like Google because that's what users expect.
But part of the problem is not just that end-uers want things to look like
Google... they want them to *be* Google! Because that is where the
end-user is doing much of their current resource discovery work - we can't
always expect them to come to us (even if what we offer them looks
superficially like Google)?
Andy
--
Distributed Systems, UKOLN, University of Bath, Bath, BA2 7AY, UK
http://www.ukoln.ac.uk/ukoln/staff/a.powell/ +44 1225 383933
Resource Discovery Network http://www.rdn.ac.uk/
|
