Thursday, June 23, 2005

Search Engine & User Readiness

As we deliver more and more rich flash experiences, we must consider how our browser experiences affect the users.

I remember when I was working with one company, and all they're folder names, file names, did not make sense.

And why do they matter to end users?

To help them remember where they are, and what part of the site they are on, and to help clue them as to the informational architecture of the site.

For example with Ablecommerce, the shopping cart part of the site was in a folder named ecom7, and the file names were really not understandable.

This does mattter, because if the customer can understand the folder structures, then it makes them easier to navigate.

Now we go into flash applications, where whole web sites, can be in one url. Which is perfectly fine.

Then here's the question:

How do we help visitors bookmark, a specific part of the flash site? I mean an article, content, advertising? If we have an intensively content heavy site, we do not want to force people to go thru 10 steps to get to the page they were originally looking for.

I would like to hear from Flash people, how they deal with these kinds of issues.

Thanks, and please comment, so we all can learn from each other...

3 comments:

  1. Wow, Craig,

    Interesting question. I think you're probably going to get a dozen "it depends" answers on this one.

    I think a lot of the decision about how to go about supporting deep bookmarks really depends on the metaphor that best describes your application. If users of your application think they are "viewing pages" when they visit your site, then I would lean toward writing the bulk of the site in some flavor of html with flash primarily as a content asset. That way, all of your content doesn't necessarily have to be in flash and bookmarks to the containing pages will work just fine.

    On the other hand, if your users feel like they are "working with a piece of software" that just happens to be delivered with a browser, I wouldn't normally persue a deep linking strategy at all. Linking to the starting point of the app is probably all that's desired. If you were working in an application written in Access, you probably wouldn't need users to be able to create a desktop shortcut to a specific record in a specific table. You also probably don't want to pass around links that bypass your security system. The same applies to RIAs, I think.

    There are actually some ways to get some of the linking in an app to work. It generally involves passing in some content id using flasvars from the browser. It can be a real pain to set up, and your users have to be provided with link data from inside your app. They generally can't just hit the bookmark button and have the position inside the app remembered.

    The shopping cart you mentioned is a good candidate for an RIA without linking being required. You probably don't want somebody to be able to link into the middle of a shopping experience. Especially if that link can be picked up by somebody else. If you want to persist the contents of the shopping cart for the user so they can come back at a later date, a sharedObject can take care of that very easily.

    As for a content manageent system, I would be inclined to think that the best place for an RIA would be for the content maintainers, not the visitors. They are the ones that feel like they are "using a piece of software".

    Just my $0.02

    ReplyDelete
  2. First off, websites in Flash are very hard to justify. Even the mere mention of a "Flash site" implies:
    - it is not a web application
    - it is taking advantage of what Flash does well for design

    To me, if you are not building web applications with Flash, I can only see it justified for movie sites, or portfolio sites.

    That said, here are a plethora of ways.

    Peter Hall described utilizing... some form of XPath or equivalent where your content is represented in XHTML. This is parsed by Flash, but you can do whatever GUI you want in Flash since you have the content. This allows sites to categorize content based on real, utilized valid XHTML files. His parsing engine is ambitious, but worked form what I saw at MXDU 2005. If you bookmark a URL, it should point Flash to the right way, but not sure if he built this in.

    Ted Patrick utilizes URL-rewriting for Flex site(s), which doesn't exclude you from search engines if done correctly. However, I have yet to see a site publicy do this and admit it. Either way, if you bookmark the URL, the server will take you to where you need to go; it's up to Flex/Flash to recognize the page you just bookmarked, which, using FlashVars is pretty easy to keep state.

    Another way I've seen (can't find the blog post) is to have each page have JavaScript telling the SWF to go to a certain section (or using a FlashVars param tag). That way, you still keep the page-to-page metaphor (I don't like this solution) but it IS the easiest way to get bookmarking to work.

    Another way is throwing Google an HTML page; smells like cloaking to me (which will get you banned sometimes):

    http://webmonkey.wired.com/webmonkey/04/44/index4a.html

    Can't remember if that article discusses bookmarks; maybe.

    Another article which address multiple techniques including bookmarking (and how to avoid frames):

    http://www.sitepoint.com/article/accessible-flash-parts-1-2

    Of course, you can do what Google recommends, and make HTML copies of your site to have it be indexed.

    http://www.jessewarden.com/archives/2005/04/how_to_have_goo.html

    Combined with FlashVars, should work well.

    The whole "#frame", or anchor tag option in Flash doesn't work right for me in my tests years ago, so I gave up. So far, FlashVars has proved to be the most useful, in combination with either JavaScript and/or server-side additions to tell Flash "what the browser URL says".

    Again, 99% of sites as far as I can see shouldn't be all Flash.

    If they are applications, the same argument holds true just like AJAX: it's not a site, it's an application, and thus the standard rules of bookmarking an "apps state" don't apply; unless you have a phat state engine in your app.

    ReplyDelete
  3. The usability of the navigation and the search engine safe (SES) nature of the URLs are two separate issues.

    I agree with you that folder names are important, but but if you are talking about web users that are analyzing the strucure of the URLs as they browse, I would argue that only developers and power users do that.

    Its interesting that you bring up AbleCommerce. At one time we were a 100% AbleCommerce development shop (4 years ago), and eventually we abandoned it because the code was spaghetti and the naming conventions and includes were hard to work with.
    There was no solid structure to it.
    We were also waiting a lot for bug fixes. Then, naturally, Able decided to move away from pure ColdFusion code so that they could protect their source. At that point we decided to build our own commerce engine, so we built it in Fusebox, which gave us a decent framework to work in. Commerce development suddenly became way more profitable and efficient for us once the code went live. The down side was the 1+ year of time it took to develop.

    A good ecommerce system should have a "breadcrumb bar" showing the drill-down process as the users dig into your web site. That is a whole lot more user-friendly than trying to analyze a dynamic URL.
    It is also pretty much a standard design technique that you see on most commerce sites. Folder names in urls are probably most important to SEO, if only for the reason that too many levels will hurt spidering. This is one reason I actually avoid SES URLs. If every variable in a URL looks like a directory, and Googlebot says "I will only spider 5-6 levels deep", then SES could actually damage what it is trying to help.

    You also have two other factors that have changed SEO forever, namely the fact that dynamic content can be indexed, and the fact that paid placement must be part of a search engine marketing plan. But that is a whole other discussion..

    A usability tip on commerce design would be to create easy to use/find/remember static URLs to product categories. For instance, http://www.somestore.com/shoes/ instead of a long, cryptic URL to get to shoe category. Setting up SES-style link on the main categories in this way alone would make it much simpler for search bots to spider the catalog as well. And I think that stores should offer two links to products.... a "tinyyurl" type link, and a dynamic link. That solves the SEO issues, but the design of the store nav and the breadcrumbs should be designed to handle the usability.

    ReplyDelete