Archive for February, 2012

Website and App Maintenance Agreements

Thursday, February 16th, 2012

Maintenance Agreements – They are — They are not

Websites and apps are not commodities and the purchasing of them is not a one-night-stand. Websites and apps are born into dynamic environments. Their full value is realized when they are maintained current with those environments. The developer relationship established during the initial development is part of the purchased value. Economies accrue when a structured relationship is maintained.

A Maintenance Agreement provides the budget to prevent obsolescence. The sad news is that a new website or app is becoming obsolete even as it is built. All three sectors of the technology advance rapidly.

  • New display and interaction devices replace the old at increasing rates.
  • There is daily industry news about greater power in databases and middleware.
  • Methods-of-use, ways of thinking about these technologies, sprint into our lives.

The users of any valuable website or app will chafe immediately when it does not take advantage of this or that new device, or some new way of searching, or some social opportunity. Staying atop these concerns is the noble use of a maintenance agreement.

A Maintenance Agreement budget also should be provided for installing important updates to the underlying software. The price should be small, maybe $250 per event, maybe two or three events per year. Security updates in particular must be done.

A Maintenance Agreement provides a management structure for all the above. There is a prioritized wish list, a clear line of communication, and a non-intrusive billing arrangement.

The Maintenance Agreement budget is not for hosting the app and ensuring its connectivity. These services are budgeted under Hosting Agreements.

GORGES would be embarrassed if Maintenance Agreement budgets were spent mostly on fixing the app. In some cases this is appropriate use, but there should be very little of this. Websites and apps are warranted for thirty days after going live and after major upgrades. Clients should test the app thoroughly before and during that period to take advantage of the warranty.

The best websites and apps pay their own way. Allocating a portion of the return for maintenance extends their lives and empowers their constituencies.

Client-side Data Binding

Monday, February 6th, 2012

Anybody give much thought to client-side data-binding these days?

OrientDB is nearing version 1.0, and it has a native HTTP/JSON interface – it supports classes, inheritance and all kinds of relationships, all the things we try to simulate with object-relational mappers when building a domain-model, which makes me wonder… why use an ORM at all?

If you’re going to do all your data-binding on the client-side, and if a graph database can natively represent your domain-model without a line of code, why struggle to achieve the same thing with server-side code and object-relational mapping?

You’d only need controllers/actions for actual business-operations. You could probably implement a thin “proxy” for operations like updates and deletes, access control and user identity, etc… You would never need to render a template, generate tables or forms or parse a form-post or implement tedious CRUD operations on the server-side.

It all sounds dreamy, and I can see this working out great for applications.

But what about SEO? The internet lives and breathes HTML. So it seems it’s not an approach that will work for public-facing pages.

Any thoughts? :-)

Rasmus Schultz has worked for web development companies, advertising agencies and a music software company during his extensive development career. His main strengths are software development and database design. Rasmus has more than a decade of experience with many development platforms, languages and standards.

Website Search Strategies

Thursday, February 2nd, 2012

Search strategies should relate to a website’s mission and message. They also need to respond to the anticipated user skills and preferences – optimal search strategies on a website for scientist or engineers would be quite different from those for the general public.

Search is really just part of navigation. In many cases information found by running a search routine can also be found by just browsing through the pages. Which serves the visitor best? … is that also what serves the mission best?

Search needs words (also phrases) for searching. When visitors compose their own phrases, will those phrase be effective in searching the website? If not, then search terms should be offered as items in drop-down lists or some similar selection interface.

Next there is the question of what will be searched. A Google-like search can theoretically see every word in the public space of the website. Will this work OK? … will many irrelevant items be returned? … or should that type of “free word” search be used, but restricted to parts of the space with relevant content?

Another approach uses either “free word” input or “selected word” input to search only prepared fields in the database. This allows the web administrators to help or control the search results, but requires maintaining those fields of search phrases.

Many choices and variations are possible. Least expensive is installing one of the free search routines, one that can be limited to just the one website, as Google can. It has quick setup, little maintenance, is familiar to nearly everyone, but in a small website it can be quite imprecise and may often return empty lists.

I recommend a careful discussion with your website’s Information Designer.

©2013 GORGES - All rights reserved
where programming meets design and lives happily ever after