Vesica Blog - Taking museum and art collections to the cloud

March 23, 2013

Simplifying JQuery Dialogs

Filed under: Tech Talk — Tags: , , , , , , — Asif N @ 12:08 am

Working on a web application that uses multiple JQuery dialogs?

You’re probably sick of rendering dialog boxes with JQuery’s .dialog() function and all of its parameters.

So here’s a tiny little function that you can include in your AJAX application at the top level via a tag, and then simply call each time you need to render a dialog. So you can effectively accomplish what you need to do in one line instead of 10.

The function below requires multiple parameters:

  1. target_class – This is the name of the class you want the dialog rendered in. It doesn’t have to exist in the DOM, the function will create it.
  2. title – The title of your dialog
  3. width – The width of the dialog
  4. height – the height of the dialog
  5. load_file – An external file or view that you want to load inside your dialog
  6. buttons – A JavaScript array containing all the buttons your dialog needs. This array should contain a button id and button text, and can be formatted as:
    buttons[0]['id'] = ‘save’ ;
    buttons[0]['id'] = ‘Save this Content’ ;
    buttons[1]['id'] = ‘default_cancel’ ;
    buttons[2]['id'] = ‘button3′ ;
    buttons[2]['text'] = ‘A 3rd Button’ ; 

As shown above, you can add as many buttons as you want using an array.  The function also created a default cancel button that will close and destroy the dialog if you pass the id ‘default_cancel’ to it.

Note that once you have the dialog rendered, you can use more JavaScript driven by the ID of each button to decide what happens when that ID gets clicked. This should ideally go in a JS file tied to the view or page you load into the load_file parameter of the function.

There are several ways to to tweak and improve the function depending on what you are rendering your dialogs for,  so please feel free to make any changes and / or share your thoughts. If you have any questions, please don’t hesitate to ask.

 

February 16, 2013

Using Vesica’s Interactive Timeline

Released in December 2012, the Vesica Timeline allows all Vesica users to see the pieces in their account on an interactive map. Getting your existing collections to appear on the map will require you to define the location of your object in the History / Provenance section in the About tab when editing a piece. Once you’ve defined the location, you can get the map co-ordinates of that location to map the object. The video below gives you a basic demonstration of how to do this:

Once you’ve added the co-ordinates, you can simply browse to your timeline by going to Charts > Timeline. In History / Provenance section, you can also add the date created, which will make sure the object only appears on the map on the selected date. The below video gives you a short glimpse of what the timeline looks like.

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 or a

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 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

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.

November 28, 2012

Thanksgiving from Vesica – Report Printing

On Thanksgiving day last week we released several improvements across the Vesica platform, along with an initial version of the report printer which allows you the ability to sort and filter your collections by any of the parameters stored in Vesica, then decide what you want to print about each one of them. Whilst a more comprehensive version down the road will allow you to build queries on your Vesica database (so, for instance, you might want to generate a view of your collection that shows you everything you have loaned out to museum X and that is insured by company Y with beneficiary Z and has a payout value of $250,000 – well, you’ll be able to build such a report, save it and re-run it at the click of  a button), the current report printing functionality allows you to build reports on top of the existing advanced search functionality.

The ability to dissect and print various parts of information about multiple pieces has been a long requested feature from many different clients – so I’m happy to say that we’re there. This year will also see us release 2 more major features – including the research / bibliography tab and the redeveloped interactive maps timeline on mapquest.

See the video demoing the new report printing functionality below or on http://www.youtube.com/watch?v=m_hBWCgcwWM.

September 15, 2012

Getting art collection reports the way you want them

One of the updates scheduled for the last quarter of 2012 in Vesica is a report building tool. Unlike other software where you can generate pre-defined reports, this reporting tool will allow you to print whatever you want on a report.

The report builder will benefit immensely from Vesica’s already powerful search and filter functionality. As it stands, you basically filter, search and drill down in your collection to view objects / pieces by a variety of different parameters – and you get to define and choose these parameters. In the current system, though, you are unable to choose what information about the searched and filtered objects you would like to print on a report. This information is pre-defined and, as such, may not be very useful to all departments in a museum.

But that’s what will change. You will be able to choose what information you want to include on a searched report of objects and pieces, just like you can choose what information you would like to print when creating a detailed object report.

So, illustrated with an example, your current search and filter interface might look like this:

Filter Options

Once you press Search, you’ll get the filtered results. On pressing the print icon on the top right, you’ll be presented with a pop-up allowing you to choose the information you would like to print about each object on the report, as shown below:

Report Printing Options

Choose and press print or export to word – that’s pretty much all you will need to do to create any report you require. This feature is currently in development and is scheduled for release in November. If you have any suggestions or anything particular you’d like to see implemented along with the report builder, please don’t hesitate to comment and share your thoughts.

August 27, 2012

Why we went with the .WS TLD

Last week I had a conversation with a friend and a colleague who really could not understand the reason we run Vesica on the .ws TLD. As a global museum based business, he was adamant that we can and only should use .COM. This has, of course, come up in the past – but no one has expressed such strong feelings. In fact, publications that have written about Vesica have actually attempted to explain why we use .ws, but I figured it’s time for an official version.

Let’s start with a bit of information of TLDs, which is the last part of the domain name as we know it. So, this could be .com, .co.uk, .fr, .uk.com, .net, etc. etc. TLD stands for Top Level Domain. TLDs come in different types, but the common types are:

gTLD – this is a generic TLD and does not tie you down to a specific country or a sponsor. Common ones you are most familiar with are .com, .net and .org.

ccTLD – this is a country specific TLD and also comes in an internationalized variety (this distinction is not necessary here). Examples of such domains include .co.uk, .fr, .es, .br, .us and so on so forth.

sTLD – These are sponsored TLDs. An example of this is .museum. Try http://icom.musuem, for instance.

So what really is the difference? A TLD helps identify the domain name. So you know that a .co.uk means the website belongs to the UK. You know a .museum means the website is a museum or is something related to one.

From a practical standpoint, this can have marketing and SEO level ramifications (and any other level if you are used to blowing things out of proportion). You can argue that from a marketing standpoint, the TLD can be very important. .COM or .NET almost always imply a larger, more dominating internet presence – it’s just how most people have been programmed to react to TLDs. If you are in marketing, this is a big issue. My personal view – it’s really quite important – but its importance depends on what the website in question really does. Most marketing people actually forget to address that more important issue.

Technically, the wrong extension can make or break your efforts. To market any application, it is probably good to have ccTLDs to market in a specific market. This is because Google will always consider a .co.uk extension as a more relevant result on google.co.uk than it will a .com or .fr extension. So it’s not just about the marketing anymore, but the wrong extension might mean the difference between you getting found or not via search engines online.

But what if you run a website or application online that is really not country specific – like Vesica. Sure, we might want to market to different countries and for that we could setup either subdomains like fr.vesica.ws or get domains like vesica.fr, but at the end of the day, the primary language is English and the application itself is always delivered on the vesica.ws domain.

The key to not getting lost on the internet is to get a generic TLD. gTLDs are considered somewhat internationalized, meaning that unless you specifically tell Google to prioritize their searches to one specific country, they are considered equal for all (unless your content really focuses on a geographic location). This is by no means a detailed and comprehensive answer (and there is a lot to this discussion that I am happy to go into should it tickle someone’s fancy) – but it is this particular issue that restricts you to the following TLDS:

  • .COM – this is undoubtedly the globally recognized and popular TLD
  • .NET – The second best, whatever it technically means (that’s irrelevant)
  • .ORG
  • .BIZ
  • .MOBI
  • There are a few more that qualify, and .WS is one of these

Now for answering the real question – why did we choose .WS? Because it is considered a gTLD and was available.

How is .WS a generic name when it is supposed to be a ccTLD for Western Samoa? Well, because an American company bought the rights to rebrand it as .WebSite and for all technical purposes, google considers .WS to be a gTLD. Unlike other gTLDs like .mobi or .tel .asia, .WS (WebSite) does not limit us to a specific medium (like a mobile device or phone) or a specific location (like Europe or Asia).

It simply means WebSite. Whilst it’s not as catchy as .com or .net, it technically can and does serve the same purpose. It’s clear from the Vesica website that we are a website and company based in London – and it’s really quite short and easy to remember.

Are there any other technical issues that can occur if you use such domains? Perhaps – especially if the infrastructure that resolves NS records for your TLD is sitting in a small island nation that doesn’t have the technical knowledge or infrastructure to support global traffic. Luckily, .WS nameservers resolve from all over the world, including the United States and the UK – see http://www.iana.org/domains/root/db/ws.html. This is primarily due to the rebranding initiative of Global Domains International. In a worst case scenario where such a spread of infrastructure is not available for your TLD, switching domain names if one does go down isn’t all that difficult as long as you own a few – and a company like Vesica that serves its customers primarily via the internet always has a plan in place to deploy such a backup within hours, if not minutes.

July 10, 2012

Secure Galleries and More Coming this Week

The update scheduled for later this week adds the of first of what will be many phases towards making Vesica galleries for individual accounts secure.

Users will be able to enable their galleries with a pass code. This means that anyone visiting your gallery will need to enter this pass code before they can gain access to the gallery. Future gallery updates will see this feature allowing you to add an additional level of security at the object / piece level. You can then choose to add individual pass codes for each piece in your account when and if you wish to include it in your gallery.

You will also be able to add the weight of an object in the system (where applicable). This option will be available in the Document tab under the Dimensions and Weight section (previously known as Dimensions).

Additional updates will follow soon, along with the release of Vesica in several other languages (see the post about Vesica being released in Spanish last month). To stay up to date with the latest developments and the innovative new functions we are developing to better manage and document museum collections, please see our features one on https://vesica.ws/features/coming-soon/.

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.

June 7, 2012

Multi Lingual Collections Management for Museums

With a user-base that spans over 30 countries, we’re often asked if Vesica supports foreign languages.

The answer is yes.

Vesica uses the UTF-8 character set, so all foreign languages – including Arabic, Hebrew, Hindi, Japanese, etc. are supported. This means you can enter information in virtually any language.

The Vesica interface, however, is currently restricted to English. The application is being internationalized, with our Spanish version due for launch in the next few weeks. In due course, the Vesica interface will also be available in several languages.

If you are museum considering Vesica but the English interface stands in your way, get in touch with us and we can get you an ETA on a localised interface.

May 23, 2012

Some Thoughts on Museum Websites and Open Source CMS

Let me preface this article by saying that I have been working in the web space since 1997. It has been in a variety of different sectors and domains, from universities and education to a variety of businesses, and now, museums, culture and art.

We have recently started work on some museum websites along with Vesica integration. As always, the question of whether or not to use an Open Source CMS was an important one, and whilst the goal of this article is not take you through the process we took our client through – it is to help share some thoughts and perhaps give museums an evaluation framework, if you will, of the pros and cons of going open source, especially given the variety out there.

Over the years, I have worked with a variety of open source Content Management Systems. Today, the popular ones that we would look to work with are WordPress, Joomla or Drupal. There are others in the mix, like Expression Engine, DotNetNuke, etc. – here’s a good place to confuse yourself - http://www.opensourcecms.com/scripts/show.php?catid=1&category=CMS%20/%20Portals - but we’ll keep it simple. There are also licensed CMS options available (like SiteCore) from established companies. Then there is the option to build a bespoke system.

First things first, launching a website on an open source system is not always cheaper than a bespoke one. This can be the case because some companies (like us, for instance), have been building custom portals for years. We have code we can reuse – code that our programmers are very comfortable with, code that our teams can customize and extend much faster than they could Drupal or Joomla, so going that route would probably be cheaper upfront for many.

But this option will tie you down to the company that builds your website and CMS for you. Even if they are willing to give you the source code when and if you decide to take your website to another vendor or bring it in-house, there is very little chance that one developer will ever have good things to say about proprietary code written by another developer – so they will probably advise you to scrap it and start from scratch. Bad advice, in many cases, but common practice.

So, before we go on to evaluate our open source CMS’, let’s rule out bespoke and commercial CMS because that will tie you in to one vendor, unless you are willing to scrap everything, and it may not be cost effective for you, or the dependency on one vendor just does not make you comfortable.

Now to our discussion about Open Source CMS. I tend to think of museums as communities and institutions – so the website should reflect as such. There are a great many technical comparisons out there between the 3 CMS systems mentioned above. From arguments ranging to WordPress is not a CMS to how complex Drupal is getting – they are all subjectively justified. But looking at the out of the box functionality and extend-ability of all of the above – for me – Drupal is the clear winner. It’s extensive eCommerce integration with Ubercart, it’s extremely powerful user / membership management functionality, the templating system, views and blocks, along with the ability to extend it with abundantly available modules (and the ability to build your own) makes it a clear winner to build community and member driven sites.

So, should you choose Drupal as the open source CMS for your website? Here is how to decide:

  • Will you ever bring your website in-house? Is that an option you would like to have? If so, Drupal will make a good fit. WordPress and Joomla will too, actually.
  • Do you want your website to be extendable at a reasonable price? Drupal is your answer. With all the modules available, you or your vendor can get away without writing much php or database level code, deploying new functionality faster. Whilst Drupal development rates may be higher than other CMS systems, it’s generally faster to build and deploy more maintainable code.
  • A website is a relatively open development project – meaning that you might want to do a variety of things with it. Whilst visitor or collections management software focuses on one thing, your website needs to always evolve and engage a wide audience. It needs to be flexible and easily amendable and manageable. There are only so many ways you can do things in Drupal- it is flexible, but it gives the developer a framework to work with, which can make a website less dependent on any 1 developer. WordPress or Joomla, in my view, don’t have the framework elements of Drupal.
  • User / Member management. For me, this, along with Drupal’s permissions management makes it a system very well suited to the museum industry.
  • Ubercart. This is a beast of an eCommerce project – extremely flexible and powerful, it is the best way to approach ecommerce in an online community environment.
  • There is already some momentum behind Drupal for museums. There are some modules available for software products that are specific to the museum industry. Vesica will be on that list soon.
  • Without making this any longer than necessary – rich featureset, powerful functionality, extendibility, and a framework that allows for consistent developers across multiple development teams.

However. Not all is good in the world of Drupal. It’s a mature product, with thousands of lines of abstract code to accommodate the wishes and desires of a wide array of developers, which makes it very flexible, but tedious at the same time. It also needs to be optimised to run as fast as WordPress would, for instance, but then that’s the cost of picking a more powerful engine to drive your site on – it does consume more resources.

Of course, Drupal isn’t right for all websites. It may be too complex where the requirements are as simple as a standalone blog, an online shop or a photo gallery. But when you want the right mix with scalability and flexibility- I believe – Drupal is one the most viable, free, open-source options available.

May 17, 2012

Museums and the Cloud: Common Questions

Here’s a list of common questions (and brief answers) that museums and private collectors with sizable collections tend to ask when considering Vesica. If you have more questions you would like added to the list or require more in-depth answers, please comment or get in touch.

Is the cloud reliable / how often would the application go down?

The cloud is reliable – very reliable. In fact, it is probably almost always going to be more reliable than any software application you deploy in-house. Sure, there are outages, but they are rare. Cloud providers like Vesica backup your data several times in the day too – so even if there are unanticipated circumstances, the application and data can almost always be brought back. Let’s put it into perspective, the cloud is as reliable as Amazon, Google, Microsoft Hotmail / Azure / Office 365 are. If you use any of their services, you are already using the cloud.

Will we really save any money?

Yes, a lot of money. Simply put, if you adopt a cloud solution, especially one like Vesica for Collections management, you don’t have to pay to purchase, maintain and upgrade servers. You don’t have to pay IT staff to setup and maintain these machines or networks. You don’t need to get into or get involved with complicated licensing or long term contracts for desktop software. This applies to virtually ALL cloud applications. Vesica can help museums save 30-60% of their existing cost for collections management systems deployed in-house. It also offers you a lot of added functionality out-of-the-box, like portability via an API, with zero additional costs or modules.

Do we need to backup our data? If so, what are our options?

Do you backup your hotmail or gmail email? If you don’t, you don’t need to back up your cloud applications either.

However, if you’re still getting comfortable with the idea of moving into the cloud, most applications will allow you some kind of an XML formatted backup which can be exported into other databases or software applications in the same industry.  You can get a CDWA Lite compliant XML backup in Vesica. You can even download all your media separately – we’re considering wrapping it all up together to let you get a compressed backup file, but for clients in excess of 100GB, many don’t have any way to open those files, so it’s best to import the XML backup into another application.

To put things into perspective, most people using Windows 7 cannot open a file larger than 4GB – compressed or not.

How do cloud providers like Vesica backup their data?

Different providers have different policies, but everyone backs up regularly – it’s part of being a service provider. Incremental backups are and can be deployed across multiple sites along with full data backups at several locations. It’s really quite safe and cost effective and feasible due to the economies of scale involved.

Will the price ever go up?

For most cloud providers, this is unlikely (at least in the near future), unless the way the tech industry works changes drastically or the US Dollar, sterling or dare I say, Euro, collapses.

Can we enter information in foreign languages?

Yes. MOST cloud applications support UTF-8 encoding which has built-in support for foreign languages. That should include everything from Arabic to Hebrew to Mandarin.

Do we need to involve IT?

Typically, no. Because for most cloud applications, all you need is a computer / phone / tablet pc with an internet connection.

How does cloud or web-based software work with our website?

Most cloud applications, by their nature of being delivered as a service, come with Application Programming Interfaces, which effectively allow you to integrate them with other applications, similar to how you would a desktop based database that you had access to (although many of these might require you to purchase additional add-ons to web enable them). Using this Application Programming Interface, you can extract information that sits in your cloud based application and display it any which way you want on your website. It’s not complicated, but it does require the ability to develop websites. Many cloud software providers also have modules available for third party CMS’ which your website may use – that effectively means you’ll be up and running with a few clicks. Vesica, for instance, will have a Drupal module that can seamlessly integrate your collections with your website later this year.

How can we get data in and out of cloud based collections software?

You can generally extract all the data as XML. Depending on the nature of the application and what you store, it may be feasible for you to get CSV files or download all your media as 1 compressed file.

As a museum, what opportunities does switching to the cloud present us with?

Many. The cloud allows you to save money and focus your efforts on what you do, whether that’s conserving, preserving, educating or engaging your community without having to worry about technical staff, technical problems, upgrades, downtime or any technology driven financial inconsistencies.  It takes a slightly different mindset to adopt the cloud, but for museums that do, it is a liberating experience.

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.

February 20, 2012

What makes Vesica a unique Collections Management Database?

Amidst all the buzz and feedback about Vesica this year, one question has come up a couple of times. This question is primarily posed by those who’ve been through the features list but have not yet created a trial account to see how Vesica works. Others, who have used it, have been kind enough to answer this question for us. You guessed it – the question is the title of this post – “What makes Vesica a unique collections management database?”

Rather than give you a breakdown of how Vesica is different (or better – and you’ll find a comparison chart link at the bottom of the article to this effect), I’ll briefly discuss one simple thing that sets Vesica apart from the competition. Aside from the obvious benefits of a SaaS application – which I discussed in a previous article here – and unlike all other databases or collection management applications in the market, Vesica is unique because it was built with a unique approach. Unlike other applications, Vesica is not just an interface added on top of a database – it is engineered to deliver a user experience. We didn’t really want to create just another Collections Management Database – that’s boring (and a white and depressing dull gray colour) – we wanted to make managing collections a fun, beautiful and enjoyable experience. Of course, on the back-end, we deliver this with a robust database in a world-class data centre (solar powered, mind you), but our interface is built from scratch – a beautiful, synchronised medley of user interface gadgets that will make using collections management software a good experience.

Not only is our interface unique and bespoke, we’ve developed a system that allows us to push the boundaries in terms of innovation. Others rely on, in many cases, open source software and applications, which means that they are restricted with features and functionality allowed within the frameworks they work with, or they would lose the support of such frameworks or open source software.

As one of our clients puts it – “Vesica is really pretty, intuitive and easy to use – unlike other collections management databases.” This is true in fact as much as it is in spirit – Vesica is not just a collections management database – it is so much more and it is always evolving to help museums, collectors and heritage organisations better document and manage their collections.

For more information on what makes Vesica unique, see our feature comparison chart.

 

November 25, 2011

Vesica charts get drill down functionality

Filed under: News,Using Vesica — Tags: , , , , , — admin @ 3:29 pm

Vesica users today will be able to drill down from Vesica charts into detailed data about their collections. This functionality makes interacting with your collections easier, faster and more intuitive. Where as before you could just visualize your collection via the pie charts and would have to search independently to get the list of objects that made up the chart, you can now simply click on the appropriate slice of the pie in the chart, once to slide it out, and a second time to click through to get a list of objects that make up the statistic.

Let’s show you how it works. Below is a pie chart of all the artists who have work listed in the account we’re looking at. You’ll also note in the chart that we’ve clicked on Vincent Van Gogh once, so his piece of the pie has slid out.

Pie Charts - Drill Down Functionality

 If you clicked on the Van Gogh piece of the pie again, you’ll go to a page that will list all 61 objects in your account which have Van Gogh tagged as the artist.

Van Gogh in Vesica

The drill down functionality has been applied to all 7 charts in Vesica.

November 8, 2011

The Vesica Partner Program

The Vesica Partner Program was launched earlier this week and is now accepting applications.

Ideal for professionals and companies who work with the museum, heritage, art or cultural sector, the Vesica Partner Program offers a host of benefits to Partners, including:

  • Additional, on-going revenue

  • PR Opportunities

  • Participation in our Webinars and at Customer Events

  • And much, much more…

Vesica is a pay as you go, cloud-based collection management software application for museums, collectors and heritage organisations. With unlimited storage, CDWA Compliant data feeds, streaming audio and video, charts and other interactive educational and marketing tools, Vesica offers museums and heritage organisations a SaaS option, enabling  them to save hundreds of thousands of dollars in IT and licensing fees in addition to gaining operational efficiency and increasing revenue streams.

To become a partner, apply today at https://vesica.ws/partners/.

October 31, 2011

Are Mobile Apps for Museums Overrated?

[poll id="2"]

The last year or so has seen a dramatic increase in all the talk about mobile apps, not just across the museum and heritage industry, but for all major sectors. From banking apps to games to photo management, from useful apps like the TFL Live London Underground Updates to the completely worthless ones like SimStapler, mobile apps are in. But are they really adding any value to someone’s experience on a mobile device, or do many companies invest in building an app simply because someone else (who is possibly competition) is doing it?

As with all things technology, building, buying or investing in something just because another company is doing it is probably the worst way to justify expending your resources. But marketing gurus, who drive much of the social media, interactive and website / mobile website policies in business and non-profit industries, will probably have you believe otherwise. For many of them, having a FaceBook app is vital to ‘staying competitive ‘- a mobile app is not different. But who can blame them – spending and job titles have to be justified if they are to stay in work year after year – but this article is not about the marketing aspect.

So museums can invest in a variety of different mobile apps – and most of the talk that you’ll see on LinkedIn groups, for instance, is all about trying to engage the visitor (without actually defining the visitor interestingly enough). But if we were to work back and look at mobile applications as tools and investments, the following questions need to be answered:

  • Will a mobile app increase visitor footfall, enhance visitor experience or keep visitors engaged with the museum longer (let’s stick measurable results here, not prophesized effects)?
  • Will the mobile app add to museum revenues in any way?
  • Will the mobile app save the museum any money in the long run?
  • Will the mobile app increase the museum’s operational efficiency or boost employee morale?
  • Will the mobile app add anything along adding to the knowledge and education of the public in line with the museum’s aims and goals?

Of course, it’s probably important to decide WHAT the mobile app will do before you go by evaluating these factors – but at the very least, a decision to develop a mobile application must, in my view, be subject to a YES for at least 2 of the above questions.

So, can mobile applications actually accomplish any of the above?

Whilst it may seem very promising from a visitor engagement standpoint, my personal view is that a mobile app will have little or no effect for most museums. For science and technology museums that target and engage a younger audience, by all means, yes – for others, I don’t think so. Most likely (and please quote statistics if they are available otherwise), the typical museum goer is actually irritated with smart phones, and at best, only uses it for email or the GPS (if they can).

That’s not to say that a well built museum app cannot serve an educational purpose – but even then, it really depends on potential visitors to show enough dedication to view the museum’s collection on a small screen – that requires quite a high level of tolerance, even with today’s technology.

I believe the real use of mobile applications lies in helping museums becoming more efficient and helping make the life of museum employees easier. Mobile apps, whether they are for phones and tablets, can assist curatorial staff or art historians in constantly managing and updating collection related data, without having to log into a PC or particular piece of software. This can be especially useful, if combined with the photography and scanning / inventory management related functionality available in today’s smartphones.

At the end of the day, there’s no right or wrong here – it’s all just a matter of how each person approaches the subject of  mobile apps for museums. My general view is that customer / visitor facing apps for museums are overrated, and will, in all likelihood, not produce a good return on investment.

But we’d love to hear other views, so please share yours.

August 16, 2011

Preview of this Week’s Update

It’s Tuesday afternoon and we’re happy to announce that the release scheduled for later this week (Friday) will not only add some new features, but will grow the application functionality in terms of compatibility and add something in terms of easier navigation and user experience. The team has been hard at work implementing some of the feature requests from Q2 of 2011 and we’ve been planning a list of features and functionality to add to the platform for later this year. So, let’s get started wth what’s coming:

Streaming Video with HTML5

That’s right, you’ll now be able to upload video files in various formats and stream (or download) them from within your Vesica account. You’ll be able to associate these video files with pieces and collections. To start off with, we’ll initially be supporting a maximum file size upload of 1 GB in the following formats: AVI, MOV, WMV, OGG/OGV and MP4. Over time you’ll see more improvement to the video management platform, including the ability to control quality and embed video elsewhere (with or without the API). The best part about streaming video via HTML5 – we can support all modern desktop browsers and most mobile devices, including the iPad / iPhone and Android based phones and tablet PCs. In terms of browser support, you’ll need IE9, FF4+ or the latest version of Chrome / Safari / Opera to stream the files. You can always download and view the files on your desktop as needed.

Audio Streaming Compatibility

In July we added the ability to stream audio files (for your museum / exhibition guides, etc.). We’ve now made some changes to the audio platform, the result of which is that you can upload any of the formats we supported previously, and they’ll play in all of the modern browsers, irrespective of the format. Previously, you were unable to play OGG files in IE 9 and MP3 files in FireFox – this compatibility issue will be resolved with the update.

Interface Changes

Yes, we’re finally adding some dropdowns for easier access to the many settings / configuration pages, the support ticketing system and the FAQs. In addition to that, we’ll be deploying some icons for the buttons you see on the site (like save, edit, print etc.)  to free up more space for your content.

A Word on Data Standards

The technical team has also been evaluating various data standards that are in use by museums across the world. Whilst there are no formal dates, in addition to allowing you to export your Vesica data using the Vesica API, we are also planning on making feeds of your collections and related details available in some of the other formats, like the Categories for the Description of Works of Art (CDWA) Lite by The Getty (http://getty.edu). Watch this space for more details on the subject if you’re interested in ‘open’ data for museums.

July 5, 2011

Vesica is now available on AppDirect

Filed under: News,Technology — Tags: , , , , — vesica-press-releases @ 5:28 pm

July 1, 2011 – Vesica is now available via the AppDirect marketplace.

AppDirect is a free web-based application which allows you to use and manage web-based applications from anywhere in one simple and secure site. It’s also a marketplace that provides the latest web-based applications. It really is based on the concept of simplifying the use of software on the internet, so we’re glad to be a part of it.

“The integration with AppDirect is another step towards increasing the global awareness of Vesica,” says Asif Nawaz, Founder and Chief Software Architect at Vesica. “With AppDirect’s single sign-on functionality, museums and other art, heritage and cultural organisations can now fully benefit from the use and pricing structure of SaaS applications without the hassle of  managing cross application usernames, passwords and security controls.”

Vesica is the first art collection related application on AppDirect.

Already use AppDirect? Sign-up for Vesica on https://www.appdirect.com/apps/552.

For further information, please contact the Vesica office on +44 (0) 20 8133 8050 or .

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