Vesica Blog - Taking museum and art collections to the cloud

January 21, 2013

Tech Talk: URL Hashing and JQuery UI Tabs

Whilst Vesica uses JQuery, what’s discussed in this article is not used in Vesica, but in a similar application we helped build at the  NHS (National Health Service) which borrows from the Vesica interface.

The application in question is a single page application, so virtually everything is done via AJAX. The URL receives different parameters via a URL hash, which updates different sections of the page DOM or accesses different parts of the interface, including JQuery UI tabs. These single page, multiple hash URLs can be called via a bookmark URL, or will trigger on a url change in the browser. What’s important to note here is that in an application like this, when you submit data, all you really need to do is change the URL – your hashing managing JavaScript should do the rest for you (in terms of routing your data to the server side, not actual processing). I’ll also show you some JavaScript to deal with JQuery UI tabs after your page loads as working with hashing will disable the default URL behaviour that allows you to call tabs via the URL.

Requirements

If it’s not self-explanatory, you need the following to accomplish this:

  • JQuery - http://jquery.com/download/
  • JQuery UI - http://jqueryui.com/
  • JQuery Hashchange plugin from Ben Alman - http://github.com/cowboy/jquery-hashchange/raw/v1.3/jquery.ba-hashchange.js and http://benalman.com/projects/jquery-hashchange-plugin/
Please load the JavaScript libraries in your page (preferably in the header) in the order listed.

How it works

Here is what we need to cover:

  1. Someone either loads a URL in their browser which is part of your single page application (this could be via a bookmarked URL or by simply typing or pasting in the address bar), in which case you simply need to pick up the URL, process, and update the page.
  2. Someone performs an action that will change the URL of your application – which should either update a database or update the page, or whatever it is supposed to do in your application.
The JQuery Haschange plugin will only help you accomplish number 2. Number 1 is simple JavaScript / JQuery.
So how does your application know that the URL in the browser has changed after the #? With the following code.

So if your existing URL looked like http://example.com/#Page1 and you changed it to http://example.com/#Page2 with an <a href> or a <button>, would see the alert box above. Note that if you wanted to to alert something anyway, you would simply put that code outside the $(window).hashchange() function.

This is the easy bit – now for how you would pick up different parts of your URL, splice them up and send them to your scripts as needed to process, and then perhaps load a JQuery UI tab on your page.

Assumptions

Let’s clarify what we have in our example.

We are trying to load a different type of product based on a type parameter, followed by an ID, followed by a bunch of parameters that style the image and options that get displayed for the product.

So, if you were using PHP and building your URL query string, it might look a bit like:

http://example.com/product.php?type=bottle&id=3426&colour=green

If you wanted to load a particular JQuery tab on this page that had the id ‘dimensions’, your URL would become:

http://example.com/product.php?type=bottle&id=3426&colour=green/#dimensions

When the page loaded, JQuery UI would know you want to load the dimensions tab and it would simply make it active.

But using the $(window).hashchange() function above will break this default JQuery UI functionality.

So, our goal, given our single page application, is to be able to reload a certain part of our page based on a URL that looks like the following:

http://example.com/index.php#product/type=bottle&id=3426&colour=green/dimensions

The way to read the above your URL is: Give me the product page with bottle No. 3426 in the colour green and display the dimensions tab on the product page. You could change any of the values above to process different data – so you could have product, category or generic types of pages, hundreds of different products and hundreds of different colours.

Sounds simple enough. This would be accomplished with the following code, and please note, as mentioned above, that to trigger this change for bookmarked URLs or those pasted in the browser you can enter this code outside the $(window).hashchange() function in a <script type=”text/JavaScript”></script> tag directly in index.php (where index.php is the file that runs your single page application) or create a another JavaScript file and include it in your index.php file via the <script> tag. To trigger it with a button click or <a href> change, please wrap it inside the $(window).hash function as shown below. Technically, you can wrap all this code in a function and call that on $(window).hashchange() being executed.

The above code now gives you access to to all the different parts of the URL hash, and will do so every time it changes. All you need to do now is use the $.ajax() function in JQuery to process this data, get the results back, and set the active tab as shown below:

That’s it, that code should pick up any changes to the URL and process them according to the code above.

As this is JQuery, remember to wrap all of the above code in $(function(){ {); as shown below. I’ve also added the code above outside the hashchange function so you can see how to setup the default page handler as well as trigger it off when the page URL changes.

I’ve stated before that you can (and probably should) write a function to do the above so you don’t have to reproduce your code twice – but this should give you an idea of how to handle hash changes and process them.

June 21, 2012

The Evolution of Technology & the Structured Human Mind

This article deals with technology, the human mind and business in and around a museum environment. Of course, the discussion is probably true in virtually all other sectors and industries, but Vesica doesn’t deal with those. Nonetheless, the attempt is to make the article structured whilst trying to deal with issues of users (or human beings) adapting back to the organic nature of the human mind.

When computers became mainstream, we had to get used to thinking in terms of using a mouse and a keyboard to interface with them. It’s not how we interface with things or other human beings in general – we touch them, talk to them, feel them and more. In addition to that, as the technology evolved, the human mind had to adapt to concepts like directories and folders in a digital environment. Of course, the very concept of organizing data in files and folders is a structured one, but there wasn’t always a structured approach to physically interface with these files and folders, until the advent of computers. Yes, you could reference them to find them, but that helps you locate and then perhaps interface however you want (as in open the folders and read, or tear them, or fold them, you get my drift). To make the concept clear, it is useful to have structured data, but the evolution of technology should, and generally does, allow us to interface with structured data in an organic, unstructured fashion.

I think, those are, to a great extent, the two levels of evolution at which the technologies we interact with, operate:-

1. Evolution of data structure for better indexing, searching and finding.
2. Evolution of technology to develop organic and unstructured interfaces to access structured data, which, in it’s structured format, can be rigid and unrealistic.

The Lotico London Semantic Web Group (http://www.meetup.com/LondonSWGroup/) had what I imagine was a great meetup on a related subject in March – which I was unable to attend – but the idea of organized vs organic meta data is actually quite similar to this discussion.

Let me provide some more evidence to suggest that this is how technology evolves, and then make the argument, that in an effort to understand and grasp structure, we, as users, fail to utilize the benefits of better, more organic interfaces, and that’s not because we are opposed to them, but because we have had to work so hard to grasp the structured concept, that we have a hard time letting go of it, in many cases, for sentimental reasons.

Let’s look at the example of mobile phones. For several years now, we’ve been able to get email on our phones. If you’ve owned a Blackberry, a Palm One / Treo, or any other QWERTY enabled email phone without a touch screen, you’ve most certainly sat there in frustration waiting for the email to open and then having to continuously click (or scroll, depending on the phone) down until you get to the part of the email you are really interested in? That’s structured data (the email content) that you have to access in a structured manner (top-down by scrolling down 1 click / roll at a time). In the non digital world, if you were reading a letter on a piece of paper, you could simply look at and read directly the part you are interested in – that’s the organic way. It may be unstructured, but it’s the organic way – that’s how we do things as human beings (even though, for arguments sake, you might have to read the whole thing top-down to make sense of it).

That’s why technology evolves, and mobile phones evolved into touchscreen becoming the dominating force. Why? It’s still a structured approach (after all you still have to scroll top-down), but it’s far more organic because you can control how much you scroll and how quickly you scroll (going slightly off topic here, but QWERTY keyboards are far from dead – touchscreen only solves our interfacing to access problem, not interfacing to enter data more efficiently). In a manner of speaking, you can decide how to get to your data, and if this part is done right, how it’s structured becomes completely irrelevant, because if you could always interface with access what you want the way you want it, you wouldn’t care about it. There are many more similar examples of technology evolution, but that’s why you have software architects. That’s also why you have architects for buildings and houses. You just know what you want, how to get it to it is the architect’s problem.

Let’s bring this same set of concepts around to museum collections, software and relational databases. Until very recently, most museum software hasn’t exactly evolved to become more user friendly. The focus has been primarily on structure (and interestingly enough, there’s no agreement on what this should be like, because there really is no right or wrong),  to the extent that a lot of museum collection software even looks like the boring, gray interface of a typical relational database. Users are expected to define their own database structure on one screen, and then use another screen to access this data. So, the typical museum software will allow you to create various record types for object genre, loans, conservation priorities, etc. Once you have these defined, you can then create an object and call this record to associate it with that object. So, effectively, museum collection software technology hasn’t particularly evolved in terms of organic, unstructured or ‘user-friendly’ access or interfaces – it’s only evolved to the point of structured data.

This is a problem, because when museums now come across evolved interfaces built on top of structured data, they tend to think the structured data is missing. Our minds have become programmed to think and access the data in a structured manner, which takes long, requires more organisation and can become quite tedious. On the other hand, think of an unstructured approach, where as you are documenting an object in your collection, you can simply enter the genre, loan information, or conservation priority as you need to, without having to open another window or keep track of any reference numbers. You’ll be able to complete the task at hand, and then later go on to manage the structured data, reuse it against another object, or do with it as you please. In essence, the data itself is still structured, you still create a separate genre or loan record and that gets associated with your object, but you don’t have to create the 2 separately. You can, but you don’t have to, because you shouldn’t have to. Just like you should be able to scroll down to the bottom of an email without clicking on the down button 20 times, you should be able to enter data associated to an object and it should automatically create the other records as part of the process, rather than you having to create those records separately.

The reason why many have a hard time grasping this approach is because it is simply not common in traditional museum software. Interfaces have never evolved, and only recently, with the push of the web and the cloud have software companies been forced to push the limits of user interfaces to access and manage data. So, when you’re using a collections management system, objects in your collection are the primary point of reference, not your loan records, not your conservation priorities, and not your insurance policies. Everything else relates to the collections and objects, and should tie in organically.

The reason for writing this article is because in a recent training session with a museum for Vesica, some trainees actually thought that type or loan records could not be re-used or associated with multiple objects simply because we were not creating them separately. The point is, that you shouldn’t have to, but an interface that forces you to do so has not evolved to become very useful or user friendly.

Think of this in terms of a blog – when you build a tag cloud or tag your posts, do you actually go ahead and define tags separately each time before you start writing a post? No, you actually just type in the tags on the same screen on which you write your blog article – the system and the interface both know what you have already used and allow you to reuse these tags as and where needed. You can go ahead and edit these separately, but creating and managing a list of tags independently of blog articles is, at best, unnecessary.

I am sure there are some interface developers who would like to further stress the importance a good interface, and yet we’ll have others who think that the interface should be just as structured as the data. But the thing to keep in mind is that a good interface deals with the way one would naturally want to access, view and manage data. If you have been programmed to only see things structurally over many years, it is very difficult to imagine a world in which an unstructured interface will work for structured data. Why would you even need such an interface?

Why don’t you use google and find out how useful the ability to access data in this fashion is? For the average user, you just enter text, which google runs against structured, indexed data to retrieve results. It works, and it works better than you having to define 10 parameters in your search query to get the same result.

As human beings and users, we must learn to think and use things freely, without the restriction of structure – that’s how we can maximize knowledge and its impact. As software architects, we must help bridge the gap between the 2. Easy to use does not mean easy to build or unstructured, it generally means well-designed.

April 26, 2012

When Museums Pay for Free Consulting

The short answer is always. And they pay more than they would have than if they paid upfront.

Following on from my last article “Museum Technology: Adopt and Adapt” which discussed how museums need to use technology to become more efficient in today’s economy, this article will address another simple concept that applies in business, but which many museums seem to overlook, with disastrous results.

First of all – there is no such thing as free consulting – someone is paying for it – if it’s not the museum, it is the person rendering those services. The concept of volunteerism has been stretched to its extremes in this industry, especially in the UK, where people are expected to work in institutions with no or little compensation for years, and it doesn’t do anyone much good. It leads to the type of attitude discussed in this article: “What would you save? Museums or Libraries?“, and when it is taken to its extremes and professional consultants are ask to volunteer their services, in the end, the museum will pay for it, and pay more – much more.

Take, for instance, the case of a museum in London that we recently engaged with. It’s a wonderful museum and has some great medieval treasures, but they are managed rather inefficiently, especially when it comes to spending on technology and infrastructure. A few years ago, when the museum was looking to invest in IT, instead of hiring a professional for advice, they went to someone who volunteered from the local hospital’s IT department. Now, that may have seemed like a great idea at the time – not paying a professional some money to gather the requirements and recommend exactly what the museum needs. Instead, this free consultation led the museum into being tied with a paid contract with the hospital, which now provides IT support to the museum, maintains their website and a custom-built collections management system – when they can. Exciting, no? What’s more, for a small collection, they are paying extravagant sums of money. Let’s put things into context, they could save about £35,000 a year if they used a service like Vesica. What, then, you wonder, could a small museum do with £35,000 a year for 5 more years if only they didn’t go for the free consultation at the beginning. That’s the price you pay for a free consultation.

Then there is the arts centre in Central London. Run by a trust, volunteers and 2 employees, this trust approached a private college in the area for advice on what to procure for setting up a website and email. Again, this was a case of getting free advice, which was a good option as recommended by those working for free (the volunteers and the trustees). The college insisted that the arts centre must buy and manage their own servers. Yes, their own servers for 5 email accounts and 7 page website. After recommending spending £15,000 and helping the arts centre procure the hardware, the college was unable to support them because their IT personnel were busy, and the centre would have to pay for IT staff’s time to get everything set up. This advice was wrong from the outset and it cost the arts centre at least £10,000 in wasted spending, which came from a grant they got to promote and support the arts locally.

These are just 2 examples of the countless ones in and around the UK – the fact is that when someone is giving you free advice, they will advise you to their benefit, which will not be in the benefit of the museum, and will cost more than an initial consultation fee.

In other words, good advice is not free. You can’t get everything volunteered, and you shouldn’t have to.

Aim for professionalism instead of volunteerism every time and all who are involved will benefit.

April 11, 2012

Museum Technology: Adopt and Adapt

Filed under: Museums & Exhibitions,Technology — Tags: , , , , — Asif N @ 12:55 pm

In last month’s post “What would you save? Museums or Libraries?” I said I would talk about basic tips and ideas to help make museums efficient. These will range from a variety of topics, ranging from technology to operational efficiency to marketing. But we’ll start with technology – as it’s really quite a simple one.

As the title of the post says, museums, like most well run businesses, need to adopt and adapt to technologies instead of creating because technology itself is not a core part of their business model. What do I really mean by this? I mean that museums should, for instance, adopt the cloud, adapt to a business model that supports cloud technologies and saves them millions each year instead of investing (or rather expending) a ton of cash on procuring hardware and software that will need to be replaced in a couple of years. If a European bank is comfortable making the move to the cloud, museums can and should rest peacefully about their fears of security. After all, museums do not carry the same level of sensitive data that banks do, despite whatever irrational, unrealistic arguments might exist against that statement. Even if those arguments are to be entertained, most cloud or SaaS providers have gone through PCI compliance at some point, which means the risk is negligible.

Back to the topic at hand, museums are not in the business of technology. They should, therefore, stop spending resources and money on trying to develop technologies and instead work with existing providers and businesses in the marketplace to further technologies useful to them and reduce costs. This is really quite a simple principle and applies to all businesses in general. Take Vesica, for instance. Just because we are a software company that employs developers doesn’t mean we should start building accounting software to manage our financials. Instead, the efficient and business-wise thing to do would be to use accounting software built by another provider specializing in accounting software, preferably cloud / web based, so that, among other things, it is updated automatically with the latest regulation and laws necessary for the accounting function of the business to run smoothly. We could certainly venture into building our own accounting software, but to what end – that’s not our expertise and would be an inefficient use of available development resources.

Similarly, a museum with limited resources should focus on what its goal is and what it is good at – be it delivering an engaging user experience, conservation and preservation of history, education; whatever that goal is – instead of trying to pioneer new technology. If museums, both large and small, stopped consuming resources on trying to pioneer technologies and instead used what is available efficiently and tried to scale it, many of them can save thousands or millions of dollars each year – sadly, though, for many, expending budgets is about satisfying the ego, not bettering the cause of the institution.

Of course, I say this in an environment where research has led to less clarification. More and more organisations and businesses get involved with museums each year, and each of these proposes their own meta data or management standard, rules and methodologies to better run museums and manage collections, or innovative ways to engage with visitors. Whilst discussion and research is necessary to develop viable solutions, much of the discussion is theoretical and generally does not lead to substantial benefits to museums.

At the end of the day, the motto of this post is to say that the museum should focus on buying and using technology that is useful and delivers value for money. Being state-of-the-art, new, cool or wanting to own the latest hardware from Dell and Microsoft is just not reason enough to be wasting money in the 21st century. That’s what the dot-com bubble of the 1990s was for and persistent pursuit of such unwarranted goals will only lead to the shutting down of museums, albeit for no good reason.

 

Subscribe to RSS Feed Follow Vesica on Twitter Join us on Facebook Join he Vesica LinkedIn Group

Home    •    Blog    •    Contact Us    •    Developers    •    Education    •    Partners    •    About    •    Help & Support    •    News    •    Privacy Policy    •    Terms of Use

Follow us on Twitterk Join Vesica on Facebook