[Sigia-l] What do you call that place between the database and the live site?

[Stew Dean]

On 13/05/07, Jay Morgan <jayamorgan at gmail.com> wrote:
> I've heard it called "sandbox", "staging", "test server", "dev(elopment)
> server".  What do you call it?

Sandbox, Dev server and Test Server are all outside of the main
workflow for deployment of contetnt.  Staging server  is the usual
term, although it may not be a server at all but just a different part
of the CMS, in which it's just unpublished content.

> Also:
> Do you actually get to work on it or in it?  If yes, how do you interact
> with it?  (Sample answers: Yes, I shape it w/ SQL.  I do QA on it.  I own
> it.  I built it.)

Depends what role you're taking. Information architects tend not to
work with the people who work with the servers.  Also between the SQL
and live site there may be a series of XML files used to feed the
site.

> Why I'm asking:
> I want to know what you all call it because I want to discuss the value of
> that intermediate space between data and live as an integral part of how to
> do Design.

What kind of design - the term design by it's self doesnt have enough context.

> I think there's more potential in that approach than in linear
> design approaches - i.e., conceive, define, design, build, launch.  This
> will lead to a presentation and an article.  Hopefully, it will lead to all
> my future employers adopting the practice of enabling their teams with a
> sandbox or staging server within arm's reach.

>From what I've seen it's already standard practice.



> Background:
> Several years ago, I worked for a content management ASP.  As a systems
> analyst there, I worked on an application called "Intranet Administrator,"
> affectionately known as "IA".  (No, this is not about the coincidence
> between that name and my current job title.  Just to be clear, I'll call it
> IA*.)  IA* was the backbone of our intranet, a 'site' used by thousands of
> clients across the country as a reference point for what was about to go
> live.  The genius of IA* is that it was a tangible, living display of the
> client's information architecture.  On my desktop, I worked in four windows
> simultaneously:
> - a SQL database UI (proprietary, I think)
> - IA* (a proprietary app)
> - a staging server (between IA* and the live client site)
> - the live site (belonging to our clients, e.g., cars.com)
> I could analyze and diagnose problems on the live site, query our database
> in the SQL UI to get at the root, then manipulate IA* to achieve the desired
> results, proof the results in staging area, and then launch to the live
> site.  (The live site had some delay, naturally.)  That three-tiered
> perspective makes my heart swoon.  No Design tool or approach has compared
> to that in my eyes.  To paraphrase Almashi, that is my favorite place on a
> company's information architecture.

Why would you need a SQL interface?  Any half descent CMS will remove
the need to worry about the database and let you focus on the content.
 I have created many intranets and each one has been very much a case
of defining the right CMS, creating the best solution and enabling
those who have the content to own it themselves.

By the sounds of it your Intranet Administration role was more
technical than the roll of an information architect (IAs are not
engineers - don't need to know SQL and may never write a single line
of code in their life).

The whole concept of 'servers' is really a implementation detail - not
anything to do with the IA it's self. When creating the work flow for
the CMS the data, site being worked on and site live could be on the
same server, different servers or hundreds of servers - it really
doesn't matter.

Stewart Dean
User Experience Person