Mobile Sites & Web Apps for Museums

March 2nd, 2010 · Opinion

Having just read the article, Web Apps vs iPhone Apps for Museum Content, by Ted Forbes, and previously looked at the posting on Museum Marketing, Mobile Friendly Museum Websites, and even written about the topic of mobile development, I have been inspired to blog a little more on the topic.

Ted does an excellent job of highlighting some of the pertinent points about the whole iPhone versus Web Application debate, but it is more than just a simple battle between two platforms. To me it is about content and how you present it to a varying audience, it is about the abstraction of that content. The reality is that many people are thinking more about the means of delivery than the actual content to be delivered?

Where have I seen this before? Well it was highlighted by my recent posts regarding HTML alternative content and the delivery of multiple versions of websites, where users don’t have flash or potentially JS enabled. Developing for an iPhone-only scenario unnecessarily shuts out interested parties and audience, for no good reason, other than poor development planning. iPhones might seem pretty ubiquitous these days, but it would be a BIG mistake to assume they have 100% market share amongst your audience.

Museums work on inter-operability and protocol all the time. They share databases, they share objects, they share information, and these follow channels. This kind of mix is a great starting point and highlights why closed platforms such as the iPhone are inhibitive.

Here are a bunch of different reasons why I think developing Web Apps for visitors is by are a superior model and strategy for museums in the long run:

Maximum Accessibility & iPad Ready! – No stone unturned in ensuring that each and every visitor has full access to the same information. Saves the need to special case for devices and provides a breadth of service. The best thing about this is that you are now officially iPad ready if you have developed a web app. No ifs, buts or maybes about it.
Seamless Development – The fact that you are simply developing another web service means that, as a development team, you don’t need to add any new dimensions. You can carry on developing within the structure of the existing web site.
Development Costs – Because are developing for a platform which your existing development team are 90% familiar with you can ring fence and reduce the potential costs. iPhone development would be much more costly and less penetrative in terms of ROI.
Open Source – There is so much prior art in the field of web apps the ability to get from 0-60 mph in no time is exceedingly easy. This helps with reduction fo dev time and costs. It also means that museums can more readily share their experiences and though their sites can share a common structure, they don’t need to all be the same.
Flash-Content – You can use flash as desired. Sure it won’t work on iPhone etc, but you can easily take care of alternate content in these cases, as you would on any setup where you miss flash.
Niche Sites & Testing Ideas - Due to the fact that rollout time and cost can be kept to a minimum, as well as the fact that barriers to entry are low, it is super easy to create new content for specific exhibitions or tie ups that a museum does. Testing ideas is also a lot easy before full roll out, which ties in nicely with Jim Richardson’s beta museum.
iPhone Interface – Despite building a web app, you can still create a standard iPhone like interface to your web app, using whatever graphics and combining them with JS. Libraries are being built that will make this task a whole lot easier.
Reliance on 3rd Party – Part of the issue I have with iPhone Apps is the reliance on the App Store, in the same way of rolling out an Air App you rely on getting a certificate for it. Developing a browser friendly web app cuts out this “unknown” from the equation. I suppose it is possible, being a cultural institution that the App Store might fast track your app approval, but this isn’t something one can expect, rely on, or anything else.
API / Web Services – Any API structure you create to service your web app can easily be opened up and made public so that other people can do cool things with the data on their own web sites.

No doubt more will be added to this list as I think of them, but for now these obvious few will do, and perhaps you would like to add your comments below too!

→ 4 Comments

Uncaching, Removing or Updating Pages in Google

February 24th, 2010 · Web Design

Given that Google now seems to think that this site has something to say about uncaching content I thought I would actually write a blog post about managing your index in Google. If you wonder how it is possible to update or to remove content, how to ensure pages are uncached and updated, then hopefully after reading this article you will be a little bit wiser.

Webmaster Tools + Finding Your Pages

Before you do anything, if you do not have the site verified in Google Webmaster Tools and setup accordingly, then you need to start by doing that. Verification is a simply 2-3 step process, and you can either upload a file they provide to your web root or paste a custom meta tag into the HTML of your index page.

In addition to being a member of Webmaster Tools you may like to see what your site looks like in Google. To do this you can search on the following “site:www.domain.com“. This will return a result set of all the indexed pages from that domain in Google. You may find there are discrepancies between www.domain.com and domain.com.

Removing Pages from Google

To remove pages from Google you need to start by adding the specific directories or files to your robots.txt file. If you do not have a robots.txt file in place already then shame on you! If you do then GREAT. Ok so, here goes:

To add a directory to your robots.txt simply past the following line in “Disallow: /directory-name/sub-directory/” and to add a file, the following “Disallow: /page-name.html“. Pretty simple right?

Ok, so now you have done that, go into your Webmaster Tools account and select the web site you want pages or directoies removed from. Once in there, click “Crawler Access” under “Site Configuration“. Having done this, click on the “Remove URL” tab and proceed by click the “New Removal Request” button. This will then take you through the process. so simply read them. As I said, unless you have the content marked as DISALLOWED in your robots file, the removal process will NOT work.

The removal process will let you take out the following:

Individual URLs
Directory or Sub-Directories
Your entire site
Cached copy of a Google search result

Now that we have looked at removing pages, let’s see about updating and adding pages.

Adding or Updating Pages in Google

To ensure your site is updated in Google, and any changes picked up, you should make sure you have set up a sitemap in Google Webmaster Tools. Down the road, when you have updated the file to reflect changes on the site, you will want to go into the Webmaster Tools control panel and from the “Sitemap” section under “Site Configuration” simply click “Resubmit” for the sitemap you wish to be updated in Google’s index.

The turn around time for any changes in the index is not quantifiable. It could be quick, it could also be very slow. I often anticipate a minimum of a week for changes to filter through. You could of course start by making a removal request for specific pages to help force an update, but this is merely a suggestion and will of course cause traffic to drop for an unspecified amount of time.

→ No Comments

Why Am I Getting So Little Traffic? – Using Webmaster Tools

February 20th, 2010 · SEO, Web Design

You might ask yourself this question. I am! I have a blog with some 80 posts on it about strong topics, including SEO and I tend to have a verbose writing style so I am not short of a word or two to index, so why am I receiving so little search related traffic on vincentroman.com compared to others blogs of I run, such as techtalkpoint.com and applemactutorials.com.

Spotting The Problem

The answer it seems would be in Google Webmaster Tools. The evidence is that elements within the design of the blog, and which are replicated on every single page are being given TOO MUCH weight within the context of the blog itself. How do I know this? Because in the “Keywords” category under “Your site on the web” in Webmaster Tools, I can see the top terms for my site, and the relevance my site has for them. Top of the list is “icon” with 100% relevance. EEEK!

Fixing The Problem & Driving More Traffic

So how do I go about fixing the problem? Well my initial effort was to simply remove the word icon from the ALT tags in the image icons of the links in the “About …” section (to the right in the sidebar), but this seems to have done little over the last couple of weeks to change anything. My current line of thought is to remove the images/icons/links altogether and shift them over to single profile-focused page “About Me”, where, surprise surprise, people can read a little more about the “Man behind this blog”.

The thought of simply adding a rel=”nofollow” also appealed but at this juncture I am not convinced that would be enough to dampen down the importance and density of such irrelevant terms to my blog. General sentiment is that only “major surgery” would fix the current symptoms, and so cutting and pasting the HTML code out of the sidebar and into a page seems like the only way to go.

Another less elegant, though perhaps more user/content friendly would be to add the social icons in via JS so that the robots do not read that content. It means the icons et al will appear, but it also mean that there will be a flicker int he content as it likely loads in in 2 parts, first via the page itself, which will render and then, potentially with a slight lag, the social media icons appended to the “about me”.

Why? Oh Why?

This might at least reduce the keyword density of terms such as icon, twitter, facebook, etc but does it make for a better user experience? I am not sure it does, which, frankly speaking, sucks! If only it was possible to block out sections of content on a page to robots, much like you can target content for the optimisation of AdSense placement, but then no doubt dubious webmasters would use such functionality for less than desirable ends.

Anyhow, I will see how things go, and with luck will see an upshoot of traffic to the blog for more pertinent terms, such as “Facebook Connect Troubleshooting” and “Steps to Good SEO”.

→ No Comments

Search Engines Love Qype

February 18th, 2010 · SEO, Web Design

It’s clear from the results of the work done on my friend’s Jensen Headshots web site (jensenheadshots.co.uk) that search engines love Qype. “How so?” you might ask, and in what way is this clear? Well here is the low down, and the net results based on my own experience of getting the Jensen web site from 0-60 mph in 1 month and the benefits of Qype in that equation.

For those who have read up on my previous posting about the site, Quick SEO Success: Is It Possible?, will know the exploits I performed in trying to get the site onto the front page of Google, but what about other search engines? Well recent searches and discoveries for the term “Headshots London” turn the site up on the home page of Bing, MSN, and Yahoo.

Often it seems like these search engines are a tough nut to crack, with an almost impossible means to get your content in, let alone to the home page. In this instance and for both these cases, however, what is clear, is that the content on Qype has been instrumental in getting the business listing, and the web site into their index. This, though, shouldn’t and doesn’t undermine the the other good SEO work that also played a part, but in reality, getting into the directory is half the obstacle.

The search results on Bing & MSN provide two links, one in the form of a local business directory listing which clearly draws the information directly from Qype, and the other in the form of a natural search link further down the page in 9th position.

The listing appears in the Bing Local Directory because the word “Headshots” is a direct match on part of the name, whilst, of course, the business is location in “London”. The obvious take home from this is that it helps to include target keywords in the business name and/or listing name on Qype and elsewhere.

Ok, so we established it is useful to get a listing in Qype, but is it enough to be in Qype with no further content? That much I can’t tell you just yet. The jury is still out. As part of the Headshots SEO process, I added more information, from photos to reviews, and I can only presume that these positive traits for the listing provides extra juice and benefit for the eventual outcome. Adding them certainly can’t do your Qype listing, and eventual business listings any harm.

Despite all that, I must say I was rather disappointed with the output of the imported text and listing from Qype into Bing. They had reformatted the business name, making it lower case and rather butchered other content. But as the saying goes. Never look a gift horse in the mouth.

Which brings us onto Yahoo. There is no clear information on how exactly the Jensen site ended up on their home page for the terms I targeted, but I can’t imagine that the combination of Qype, Google Local Business Center and even the SEO on the site, all played their important part in the equation of search engine optimisation that brought the site to the fore. What is clear though is that the site alone, without working in tandem with Qype and Google Local Business Center would NOT have ended up in Yahoo so quickly and readily for those terms. Call me a cynic, but that’s just my experience.

Anyhow, more interesting food for thought on my fave topic of SEO.

→ 1 Comment

User Experience & Why HTML is Not Just a Wrapper

February 16th, 2010 · Opinion, SEO, Web Design

The on-going argument about Flash on the iPod, iPhone and newly launched iPad, still raging and the spat between Apple and Adobe very much still out in the public, it is clear that Flash won’t appear on the devices any time soon, but is this really such a big deal?

Experience Versus Information

As a front-end dev for a company that builds primarily Flash experience web sites for ad agency clients, I am acutely aware of the benefits and pitfalls of Flash. In some ways I am happy that Apple is pushing back on Flash. Not because it means there is more work for me, but ultimately because it means that companies will be forced to build better enhanced user experiences outside of Flash.

The advent of Flash and similar technologies, to my mind, has fostered an air of sloppiness. This is, not to finger point at Adobe/Macromedia, the side effect of slack work from company-after-company. Sites that should contain information rich content in HTML, as well as Flash experience, are turned into pure wrappers for flash, forcing HTML to act as a mere delivery agent. In short, if you do not have Flash installed, the page alerts the site visitor to download Flash rather than to supply them with proper alternate content and perhaps what the visitor was actually looking for.

As an end user I would hate to reach a site and be forced to download Flash to view it, and in the mean time, be faced with nothing more than a dead end hole, with ZERO information. As a producer you are turning potential customers/clients/audience members away and surely this should be frowned upon. Developers talk about progressive enhancement and graceful degradation, but surely this should stretch out as much for the look and feel and function of a site, as for the eventual content contained within. All aspects of any site should be inclusive not the reverse.

Identify Your Audience & Cater To Them

Imagine you have a flash experience web site. 20% of the visitors enter it on an iPhone, and then imagine you have no decent Flash alternative experience. What kind of message are you then conveying to those interested parties? In my book, an exceedingly poor one. You are telling them, that you message is not important to them, or that they don’t matter. How often do you get a second chance to rectify that? Not very often I would imagine, and therein lies the need to get it right first time.

The audience is as much about the type of people as the types of devices they are using to access your site. You need to profile on these two dimensions and cater to them properly.

Don’t Special Case At Another’s Expense

When I say cater, I don’t mean special case them, though of course you want your brand to show up it best on every single device available, within each of their limitations of course. The problem though I see, with the entire fanfare around Apple and its products is that developers and clients are again talking in very specific terms about user experience and what is offered to site visitors, at the expense of the market-wide experience.

I know this isn’t a post about Apple and the pros and cons for various features on their devices, but I think the iPhone and now the iPad represent very real issues in terms of the eventual user experience cross-platform on the web. Pardon the pun, but these devices are divisive and where for the last decade or more developers have been encouraged to take an all inclusive approach, with the popularity of Apple products clients are now demanding an Apple-centric experience, but even at the expense of other devices, be they desktops, phones or tablets.

What Can We Learn?

What can we learn from over 15 years of web development history? Well for starters, that in the same way we need to continue to cross-browser test for IE6 till 2014, developers and their clients need to think long and hard about what kind of experience they are building and deploying for ALL site visitors, not just a subset, and do they have all bases covered.

Providing a dead-end to site visitors is never a great option, even if a minimum of well presented and formatted information is required to ensure that they head off to another place that might be more useful to them. In the same way that user experience specialists will frown up an empty 404 error page, we shouldn’t allow mere “install Flash” pages to be served up.

And for those who take the time and effort to optimise the user experience at every single level then there are dividends. For one, the code represents better SEO prospects and when you post a site to the internet, you do of course want it to be found, even if you are marketing it. Those marketing keywords are ALWAYS important, especially so when you are directing potential customers to use them.