Can you see a slide rather
than something else?
Cool. OK so I'm Tom Crane.
I'm technology director of Digerati and
we've been building a manifest editor.
Now that's something that
already exists surely,
and there are lots of tools out there
that allow you to construct your belief.
Things, there's lots of precedent here.
A lot of precedent from from us.
We've been doing this kind of
stuff for quite a few years,
and there are some fantastic.
Tools out there like annotate and
exhibit that do kind of related things,
so I'm just going to look
at some precedent from us,
plus the body and editor.
I'm not going to look at any other
precedent because there's just
so much fantastic stuff that we
could talk for hours about it.
So yeah,
so we've been building kind of
things that make manifests for
various purposes for a long time,
and the broadly in editor is a thing
that makes manifests for general purposes.
That is a kind of venerable piece of
software that's been around for a long time.
So what we wanted to do was,
can we build something that allows people
to build presentation 3 up-to-date,
IIIF manifests and also
can replace the various kind of
ad hoc or bespoke tools?
That we've been building over
the years that that build.
What are essentially manifest with
annotations but that are designed
to drive bespoke user experiences?
And you know, we've done a few of these.
We built a manifest editor a few
years ago for the DNA and the
Delft University of Technology that
allowed the construction of of
slide shows and enhance the manifest
with custom behaviors to determine
how transitions occurred or the
placement of particular panels.
The same manifest editor as the
basis of work for Delft University
of Technology that allowed much more
complex kind of exhibition construction,
including multiple kind of collage.
These canvases with multiple images
on them and complex layouts. Umm?
These things though required.
Lots of work every time you wanted to
add new features because they needed
their own kind of preview environments.
They needed to configuration to
customize the user interface and
it was a lot of work to maintain
a manifest editor that kind of
required all this stuff when you
wanted to do extra things.
And you know this idea of annotation
driven storytelling on top of manifests.
You know that's been around for a long time.
This is something we did six
years ago for for welcome library.
Yeah,
that includes nice triangular
annotations that you can rotate to look
at different builds, bits of a quilt.
So these are all background use cases.
We did some user research to see
if we could kind of understand the
different needs of people who want to
create manifest and see if there was,
you know,
possible to produce a tool that could do.
All these things.
So here's our user research process.
We started by gathering everything
we did know and we had a kind
of preliminary product strategy
where we just tried to identify what
is the vision of the thing we're
trying to do, or our objectives.
Who are our users?
What would success for those users mean?
What would it look like?
What problems are they trying to
solve and you know from our users,
some of whom were real and some
of whom were kind of ideal.
We recruited a pool of users for testing.
And then we and then we kind of went back
and created a better product catalog product.
The backlog prioritized that
we could begin to action rather
than just be kind of stories.
I went through a design process
involving mixture of wireframes
and technical design and kind of
actual test implementations using
bootstrap JavaScript to test out
particular user interface ideas,
and then we have the last few weeks
we've been iteratively building the
manifest editor, and we're kind of.
Maybe number of reasons we're not,
you know, we're nowhere near finished,
but it's coming along and I will
show you in a in a in a bit.
So yeah, as I said,
kind of use a mixture of wireframing
and a kind of narrative based
user story where the the user
story is kind of a detailed user
journey that's then annotated with
technical details and GitHub issues.
And then you know bootstrap
prototypes like this one.
You can see in the bottom here.
So what was the product vision we
came up with? There is a link to it.
I'll share the links to all
these slides at the end,
but there is a link to
the product vision here.
But just to summarize it,
you know the fact that most manifests
of published by automated workflows,
you know there are hundreds of
millions of manifests in the world,
probably billions by now.
Most of them are made by machines,
their data transformations, other sources.
But you know the kind of practical,
practical IIIF ability to handcraft
manifests you know opens up lots of
applications for research and scholarship.
We heard lots of user stories about kind of
remixing and extracting combining different,
many different existing
manifests into new manifests,
deconstructing very large
manifests into smaller manifests,
creating these digital experiences
for spoke content for digital
user experiences and exhibitions.
Now our users, you know, this.
Ideally,
this tool should be useful no matter
what your expertise in IIIF is.
If you're a IIIF expert.
There's no kind of problem with
hand editing it in a text editor.
You might want to use this tool
as an alternative to doing that,
just because it's nicer if you're
attending a IIIF training course
and learning all about IIIF.
If this tool should be something
that actually helps you understand
what what it is you know the
use of the tool should help you
understand how IIIF works.
And if you don't care what
your life is and never want
to learn anything about it,
but have been given, say,
a content creation task to produce
a manifest, the tool should be
usable without having you know,
having to buy into anything you
know you don't have to understand
how PowerPoint file works under
the hood to make a slide deck.
You know that that audience is
a significant audience too.
So I'm going to jump in and
show you some stuff now.
The current UI of this is kind
of preliminary, so it's not.
It's not it's finished polished version.
If I just jumped into
the manifest additional,
I've never seen it for the first time.
I'd get a splash screen.
That kind of just gives me a
little bit of text about or
in or in orienting myself,
but I could just jump in
and start creating stuff,
but I'm going to open a manifest.
And that obscured by the zoom stuff.
Of course, that did,
so just just to start off with.
I'm just gonna go and open and manifest
that I've found or been given.
I'm being warned that my
Internet connection is unstable,
so I don't know if I'm phasing
in and out here sounds alright.
OK, if if you need me to repeat anything,
wave at me and I'll try and.
OK thanks. OK alright so I'm just
going to go and load this manifest
and you can see it kind of works.
It's it's viewer like I've got thumbnails.
I I've got the manifest details.
I've got different views.
I could go into,
maybe a more kind of PowerPoint style
view where there's a central canvas
where I've got my deep zoom capability,
but I've got a thumbnail
stripped down the side.
Or I could go into that kind of
grid view where I can even kind
of rearrange things and drag
canvases around and reorder things.
Or I could go into an outline view
and this was interesting from
the point of view of learning
about the kind of ideas here.
Maybe for more technical users who
who would want to be interested,
be interested in seeing this
kind of aspect of it.
You know if you open a big project
in a in a in a code editor,
you might see lots of structure.
So the same thing here I can dive in
and start looking at the canvases.
As I dive down into these things,
you know the the kind of contextual
thing that would edit that property is
available to me on the right hand side.
Suspect that many users wouldn't
want this kind of view,
so they'd be happier with this kind of view.
But let's kind of keep it.
Keep our options open for
different different users.
And it's going to close this
and start a new manifest.
Where's my window?
Let's go. OK, let's just go and open.
We've been this right.
But we still here have.
I still got Internet. OK, right?
So one thing we wanted to do with this
is to really be as flexible as possible
for what the user might be trying
to do or think they're trying to do.
So I've got some examples here.
So supposing I want to add a canvas now
I've just gone and grabbed some test
images here for what to make this easier.
So here is an image that's on the on the web.
And I put this in here.
Now we imagine that unlike PowerPoint,
if you're creating a canvas,
you're probably going to be creating it
from something rather than creating an
empty space and putting things into it,
which is the kind of slide model,
so we've kind of gone with the assumption
that all the default assumption that you're,
you know your motivation is to
create more things from content.
So if you put an image in there,
we'll measure it and say I'm going
to create a canvas that's this size.
Just add that one if you.
Another one, if you create a say.
That's true. And grab another image.
Have another one.
At the canvas you know I can just I
can just do things like this and I'm
I'm not consciously creating canvases,
I'm just kind of adding content.
But if I needed to, I could,
for example, place.
I've lost my links, let me what,
what if someone had given me
image services rather than
static images I can go and.
Add chemises from them too.
The same dialogue.
I don't have to think about what I'm doing.
Here I'm you know I've pasted an
image service URL with analysed URL
identified that it's an image service,
not an image,
but it doesn't make any difference
to the end user that can
just create content from it.
I might also decide I'm a kind
of advanced user and I said no.
Actually I do want to make an empty canvas.
I really do want something that's more
like a PowerPoint slide that I can.
I can go and put content on and
I could create a canvas that way,
but I'm not going to do that
in this session there was just.
I don't know what this to make it.
More interesting.
This one. OK, so one more one more image.
OK, so here's my here's my hit.
So yeah, I'm generating a
manifest and I'm at this point.
I'm thinking what does is actually look like.
I could go and preview it in Merida.
What does it look like in meridale?
OK, it's coming along.
It's looking alright.
Getting some weird labels down
here but but it's working.
I can preview stuff OK,
so now I did notice in the
mirador that my name is
not particularly friendly,
so let's try and improve that.
What's this?
OK great great. Table now.
Again, another kind of balance between
the the complexity of the structure of
relief and the kind of simplicity of user
interface is in dealing with strings.
There are lots of strings that users
need to enter when they create manifest.
Most of the time you're going to have.
I'm thinking about a label
and I'm gonna put it in there.
But Chipper Leaf actually requires you
to state what language your strings
are and also allows you to have
multiple values for those strings.
So in this scenario,
you know I've just gone and done this,
and if I preview again, hopefully.
Meredosia now has webinar, but what if?
There were actually several
strings I needed to put in here.
I can go in and create some new ones
so I can say that I can say hello and
say this is in French. For example,
all these things are configurable,
so the dropdowns the languages available.
You can add new ones, etcetera.
I can even add multiple languages in the
multiple values in the same language.
And so on and so on and so on.
So you know, and then these
get hidden behind these.
These more complex things like
always see that there are
actually three values for this.
Similarly with the kind of metadata.
We try to keep it as low.
Yeah, kind of low complexity as possible.
But the ability to edit multiple
complex language maps is still
there behind the scenes.
I can move these around if
I want to change the order,
do another preview.
OK, now we've got Hello Tank
webinar and we've got some metadata.
One of those things didn't come out,
and so yeah, so this is called now.
You might have been wondering how
am I managing to preview these
things so one of the one of the kind
of problems with hosted manifest
editors that are just kind of sitting
there on the web is what do you
do with the stuff you creating it?
Where do you put it?
So what we've done is create a very
lightweight service that runs which is
not a requirement for the manifest editor,
but it's just a kind of useful
side thing which will just host.
The manifest you create as kind
of as links and there are preview
links and there are permit links,
so I could actually save this thing
to a more permanent location.
This this isn't it's permanent location yet.
This is a test one and you can see
here it's just going to grab this if I
go and open this here is here is my manifest.
It's on the web.
I could share that it'll
stay there for a long time.
Not saying this is digital
preservation but it will.
It will stay there for a while.
And this this is an example of
integrating the manifest editor with a
a service for the persistence of IIIF.
so,
that you know out of the box
it's integrated with this.
Just kind of lightweight hosting service.
But but you could.
You could replace that with your
own endpoints so that you can
hook it into your own systems.
One thing I might want to do is
use this manifest I'm creating
in a presentation to environment.
The manifest I'm creating
here is presentation three.
This is a presentation 3 manifest.
But supposing I needed a
presentation to an environment,
I can export this thing as presentation two.
I get a little warning saying you
might lose something if you do this,
but I can.
I can take a presentation 2
versions away from this tool.
Just going to go back to
the slides for a second.
I can find them. Where are they?
There they go oops? Right yeah so.
That's a kind of brief
view of the tool itself.
It's going to look at some more use cases.
Because the kind of wider use cases are,
you know, assembling manifests from
multiple media sources, not just images,
and then this integration requirement
that a manifested itself on its own,
is kind of handy,
but you need to be able to plug it so
that things like the the file open
menu or the save menu or the preview menu,
or the browse to import menu can
all have configurable endpoints,
so you could hook them into
into your own systems.
We want to be able to create manifest
kind of completely interoperable,
but also at the same time.
Drive custom viewing experiences.
So again, the config.
You know the behaviours that are
available to you out of the box
are standard IIIF ones,
but you could configure additional
behaviours that are available in your
environment to to to drive whatever
extra functionality you need now.
One difference between this tool
and maybe a bodily manifest editor
is the kind of how far do we go
with annotations on canvases.
If you want to meet some of those
use cases that we saw for Delft,
we actually need to be able to position.
Media at different places on the same
canvas and we need to be able to draw
boxes and annotate the canvas with
labels and descriptions and text and HTML.
Support advanced composition
features and colleges.
So these are all kind of feature things
which are in in the GitHub issues,
but aren't in the preview yet.
Yeah, so and then this other this other
kind of consideration came up because
as we were gathering the use cases,
some of these many of the use cases were
not specifically about editing manifests.
As in here is 1 manifest in the
tool that you are adding things to
or you know creating from scratch.
They were about reorganizing
existing manifests, cutting them up.
They were about building IIIF
collections rather than manifests as well.
They're about using kind of specific
tooling in a leaf context that isn't
actually manifest editing or isn't visual.
Things like you know bulk tools for
pagination and things like that now.
These are all considerations and
I'll get to the kind of implications
of some of them in a minute.
But our biggest consideration
is about persistence.
It's this kind of idea that.
A IIIF manifest if you
approach it thinking it's going
to work like a slide deck.
You're going to have
problems when you try to,
you know,
when you expect that you would be
able to get images off of your desktop
and like put them in the manifest.
A triplite manifest is more like a web page.
It's a document full of links to resources.
If those resources are already
there on the web,
you need to add them into the
manifest and make links to them if
they're not already there on the web,
you need to put them on the web somehow
and the the place you may put one to
put them may not have anything to do
with where you want to put the manifest.
So how do we solve that stuff?
This is the kind of big
problem with persistence,
so we thought you know,
in developing the manifest editor,
we kind of shortcut a lot of
that by providing an out of the
box persistent solution.
For the manifest itself that
demonstrates the pluggability,
but we have not yet done anything
to demonstrate integration with
persistence of assets of images.
But we want to make that pluggable too,
so that if you do have images,
you know desktop there's a hook in
the manifest editor when you add a new
canvas or add content to a canvas,
you'll be able to, say,
send it to that service, so I can.
It can be hosted for me.
Yeah, so this is this,
you know this this need for infrastructure,
a manifest on its own.
It's no good unless you host it somewhere.
But even if you managed to
host the manifest somewhere,
it's no good unless all the things it
points out are also hosted somewhere.
So it's that kind of need for infrastructure.
And that kind of brings us to something
that came out of the user research
that we thought kind of was obvious,
but actually wasn't all that obvious
about what exactly we're building here.
Yeah, because with all this talk
about services and hosting,
the manifest editor itself is an open
source JavaScript application under MIT.
Anyone can take it from GitHub
and host it wherever they like.
Do what you want with it,
extend it we want to make it completely
pluggable and flexible so you can
adapt it and put it into existing.
Tooling and workflows connect it to your
content management system or repository.
Umm? But in order to, you know,
for it to be useful to someone,
or to have someone to kick the tires
or get an understanding of what it is,
it's no good.
It just being a repository on GitHub,
like the body in editor.
It needs to be hosted somewhere and
also it needs to have persistence
at least of the manifest.
So if you go along and play
around with it and create a cool
manifest from existing resources,
you get a permalink you can
take away and share with people
and show them what you've done.
And thinking about those other use
cases about the kind of you know,
adjacent tasks that people want to do,
we've built the manifest editor as a kind
of combination of a shell application
with the manifest editor itself being
an app that's loaded in the middle.
Because the shell can provide the same
services to other kinds of applications,
so you know things like loading,
IIIF browsing for IIIF,
managing saving of IIIF,
state management of resources
you've loaded into the tool,
and undo and redo stack previewing.
These are all services
that could be you know.
Could be services to multiple
kinds of applications,
not just to kind of pure
visual manifest editor,
so we've kind of separated out the components
of the tool into these these concepts.
And I would urge anyone who's
interested in this to go and look
at the wiki that we've got on our
on the GitHub site for this page,
which kind of just just talks through the
ideas about how this thing is constructed.
It's architecture because we really
good to hear other people's opinions
on how this would be good to fit into
your into your various environments.
Just something I want to come back to again.
We did a lot of prototyping using
sort of bits of bootstrap and
and wireframes as well,
but thinking about this issue of.
Like just not requiring the
user to make any decisions
that we could possibly help them make.
So anytime you bring in some
content anytime there's a URL.
Let's learn about as much as what's what's
on the other end of that URL as we can
so that you know you don't have to kind
of think about what's happening there.
Don't don't prevent the user from controlling
that, but just fill in as much as we can.
So if you think even just linking to
an image or a video or something,
asking someone to fill out this form.
Is one thing because most of the stuff on
here we could actually fill out ourselves by,
you know, just interrogating what's
on the other end of a link.
So generally that kind of idea of
of making the tool do the work,
not the, not the user do the work.
It is kind of central to the
way it's designed.
The other big challenge is.
We could say we're going to stick
to a certain number of features and
not support UI to edit the others.
But how do we know what you're
gonna load into the tool?
You know you could bring any manifest
to the tool and we don't want to break
people's manifest just because we
haven't got a particular complex user
interface to support the structure
that they've got in their manifest.
So it's kind of dealing with that.
You know what's the kind of baseline
where we won't break anything
that people load into it,
as long as it's valid,
but we weren't necessarily offer a complete,
wonderful visual environment for
every possible life construction
that you can think of.
That's a pretty tricky question to solve,
so we're still working on on that one.
Just a quick word just to finish off
about the foundations of this tour.
It's built on a library called Vault
which is used for state management and
loading and saving and normalization
of leaf and it's built on the visual
component called Canvas panel which
provides the kind of viewing surface or
annotation service surface for canvases.
Vault is in 555 Commons and canvas
panels still under development.
OK,
I should probably stop because I think
I've taken up at least 25 minutes.