Notes re. the tv.1 interface, working toward tv.2

Jeff and Scott, thanks for your notes.
I made a categorized, "scroll-like" list of outstanding interface issues,
All "decisions" are pending Roger's response when he gets back.
Let's move some of these along...

== CURRENT STATUS ========================================

2nd generation HTML prototypes are on

and downloadable from


The main changes are:
  o  a cleaner look per Jeff's and Scott's suggestions
  o  navigation bar on each page
  o  server identification in the title (!)
  o  a documents page, news and release notes pages
  o  the home page is index.html

Things not done include:
  o  new performance charts (Jeff and Roger should talk about these)
  o  logo change (Scott, will you look at this?)
  o  limitations to time, bandwidth, whatever (Roger, please comment)

== OUTSTANDING ISSUES ========================================


DW> Are we ever going to have more than one Terravivo server per network?
    Or for that matter, per host?  Assuming it's possible, we need to
    identify the one we're talking about.  I've used the IP number throughout
    (e.g., but a string indicating host:service name would be
    better (e.g., "origin:terravivo2").
JB> I can't think of why we'd need more than one TV server per host or
    network, but it seems like a good idea to specifically name it and
    reference that name on the interface pages.
DW> Ah-ha!  I moved the server identification to the HEAD/TITLE bar which
    seems to work out great -- it's always available yet out of the way.
    I'm using the string "origin2:terravivo" but ""
    would be better yet.


SD> [ ... likes frames or sidebars, gave example ]
JB> [ ... doesn't like frames ]
JB> The Heidelberg SRS database search system has an interesting ...
DW> Ach du lieber!  That's one way to obfuscate a simple idea.
    This is a good example of the the problem with the current Daylight
    website opening page (and why we're going to change it soon!)
DW> I don't like frames either.  And form-based popups seem heavy-handed.
    Something that I've seen work well is a header "navigation bar" on all
    pages: it can be both convenient and unobtrusive (as long as it doesn't
    include obnoxious graphics!) I've implemented a nav bar on the 2nd
    generation set of HTML pages.  I think this is plenty strong and
    addresses Jeff's concerns about losing simplicity.  Will this work?

[ ]----- PAGE TITLES

JB> I suggest we just call the TV home page "TerraVivo - main menu" and
    let home page refer to our Santa Fe site.
DW> Well, I don't like "main menu" much.  For one thing, currently it
    doesn't look much like a menu (even less so with the navigation bar).
    Plus, we'll probably put other stuff on there as time goes on which
    might be even less menu-like.  My current feeling is that the main
    page should be called "Terravivo home page", which corresponds to
    the navbar "Home" link.  That being said, something other than "home"
    or "menu" might be better yet, if we could think of it.

[ ]----- STATUS PAGE

JB> For the status page, the first block and manager's message are good.
    I don't find the status table useful.  I think the most important
    data to communicate is: am I up to date and reliable?  That's why I
    envisioned leaving most of this (redundant) data accessible to users
    through the config menu.
DW> In the current scheme, only the manager has access to the configuration
    page.  IMO, the table on the status page is doing just what you intended,
    i.e., what is available, is it current, access warning messages.
    I'm not sure users ever need to see the "primary server" column, but
    it's good for orientation.  I particularly like the idea of showing
    the users all possible resources (instead of just the available ones).

JB> ... envisioned a status menu with several bar graphs and a XY-plot.
    The graphs should convey a much clearer picture of the system's
    status than a table of numbers.  Why show numbers if you can show a
    graph - unless the invidual values are important. These aren't.
    To summarize again, the graphs are:
    * bar: %up-to-date for each database as of now.
    * bar: 2 bars per database, size in Mb and # sequences for each
	   database as of now.
    * bar: #consecutive failed updates for each database as of now.
    * bar: 2 bars per database. avg # user accesses per day for this month,
	   and since startup, for each database
    * XY plot of free disk space (Y) vs time (X), sampled daily.
      Probably don't need regression curve.
DW> I agree that we need information of these types.  Graphs are OK
    (though they don't replace data tables which can be linked).
    Most of these don't make sense to me:
    * bar: %up-to-date .... what does this mean?
    * bar: size in Mb ... in what apparent format or internal size?
    * bar: #consecutive failed updates ... I- II- or total failure only?
    * bar: user accesses .. MB delivered or number of times touched or what?
    * XY plot of free disk space ... note that this can change invisibly
      and dramatically depending on the current internal format and
      compression policy for a database.  Should this be replaced by a
      warning if they're running out of room or something like that?

JB> For the configure menu, how do you reach it if you're not the manager
    - or is this page reserved for only the manager?
DW> It's for managers only.

JB> I'd replace "incept date" with "startup date".  Incept is an unfamiliar,
    rarely used word; why use a fancy word when you can use a simple one?
DW> Just having a little fun ... it's a reference to Blade Runner ... one
    of the "bugs" in Nexus-6 replicants is that for some reason they don't
    know their incept dates.  Our robots will know better, so they don't
    have to come back and destroy us ...

JB> The proxy server port # is missing.
DW> No it's not ... see the configuration page, bottom line first section.

JB> The menu only lists the installed version of tv; I'd like to see it
    also list the latest version that's available.
DW> It's self-installing, so why would there ever be a difference?
    As I understand it, the installation will come from the same place as
    a site would get the information that an update is availale.  Not doing
    the update is not a choice, it's automatic.  If an update fails for some
    reason, then the server status will be "degraded" and there will be
    warning/error messages.

JB> I don't see any need for a 6 hrs update choice.
DW> How frequently do you think the factory terravivo server should be
    polled? In any event, these choices will be configurable on-the-fly
    for each resource, independently.

JB> Is 'once only' equivalent to 'now'?  We should provide an immediate
    update feature in case somebody needs the data RIGHT NOW.
DW> No, it means "get it once then don't update it".  It might be gotten
    now, or part of it now (perhaps over several days, as normal scheduling
    permits).  But once it's complete, it's not updated.

    The idea of "do it RIGHT NOW" is interesting.  That would be a special
    action rather than a scheduling option and I guess it would allow
    terravivo to over-ride the limitations (just go for it, use as much
    bandwidth as possible?).

JB> we provide a default update choice: 'let TerraVivo decide', which
    would poll our Santa Fe site, compare each database's status, and
    determine whether an update is necessary.
DW> That's the "poll" option, used in the software (which isn't updated
    very often).  My gut feeling is that "poll" is not ideal for everything.
    It would be nice to have these servers operate independently ... e.g.,
    if they can't connect to the terravivo server, they keep running OK.
    In the config menu, the choices marked with a '*' are the factory
    recommendations based on how frequently the resource is updated.
JB> This probably won't be practical until we have biothor, though.
DW> I don't see what biothor has to do with this issue.

JB> I'd like another column in the configure menu to select email
    addresses of users who should receive email status updates ...
DW> Yes, that's the "agent feature", which I assume will not be part of
    the initial release.  When we implement agents, I think it should be
    oriented per user (or per e-mail address) *not* per database due to
    interface scaling issues.  Do you really want to scroll through the
    list of all other users interested in a particular resource?  Even
    if so, should you be able to?  My "knee jerk" approach to an agent
    interface would be to do something similar to the configuration page
    used by the manager.  Another approach would be to have the agent
    operate completely by e-mail (subscribe, unsubscribe, get status, 
    get data) and limit the website to mailto: shortcuts, management
    and perhaps another chart on the performance page.

JB> We also need to add a limit on the total amount of time allowed for
    each tv update (not per database).
DW> Or something like that.  Bandwidth utilization is perhaps more
    relevant than time (e.g., MB/day).  Need to work on this.

JB> We should provide both "Restore" and "Factory defaults" at the
    submit changes section.
DW> Or perhaps an explanation that Shift-Reload is Restore.


JB> Roger and I discussed shipping systems preconfigured with data already
    loaded.  This gets impractical really fast ...  we should ship empty
    systems ...

DW> Why?  If we could build a purely self-installing system which is
    practical, I'm all for it.  But I don't see why preconfigured data
    would be "impractical".  Contrariwise, it seems that there are lots
    of good reasons to do so: terravivo will bring itself up to data from a
    given state, so why not ship the latest convenient state for commonly-
    requested databases such as PDB and GenBank?  It seems that this would
    get people rolling quickly, allow near-instant installation testing,
    and save a lot of bandwidth.  In the extreme case of a slow connection
    (the 3K/S we're familiar with) downloading 100 GB would require 414
    full-time days!  If there are copyright problems with some databases,
    we can deal with them or if that's not possible, they wouldn't get
    preloaded.  But what other types of impracticalities am I missing?


DW> I think we need to develop a control lanugage for terravivo downloading.
    I'm kind of a tree-head, so I was thinking of a control file structure
    which looks something like this:

      /*** terravivo update 42 ***/

      terravivo { "Terravivo Release 42" }
        version   { 42 }
        released  { "15-Dec-1998" }
        copyright { "Copyright 1998 (c) Metaphorics LLC" }
        ... various resources ...
        resource { "h_pylori" }
          name   { "Helicobacter pylori complete genome" }
          type   { "Complete genome" }
	  freqs  { "daily", "weekly", "monthly*", "once only" }
          primo  { "" }
          secundo{ "" }
          source { "" }
	    name  { "National Center for Biotechnology Information" }
	    domain{ "" }
	    method{ "ftp" }
	    file  { "/tv/genomes/h_pylori/h_pylori.fasta" }
	      src  { "/genbank/genomes/bacteria/Hpyl/hpyl.faa" }
	    file  { "/tv/genomes/h_pylori/h_pylori.genebank" }
	      src  { "/genbank/genomes/bacteria/Hpyl/hpyl.gbk" }
          source { "" }
	    name  { "The Institute for Genomic Research" }
	    domain{ "" }
	    method{ "ftp" }
	    file  { "/tv/genomes/h_pylori/h_pylori.fasta" }
	      src  { "/pub/h_pylori/GHP.seq.gz" }
	      conv { "gunzip -c % | seq2fasta"  }
	  ... other sources ...
        ... other resources ...
        resource { "terravivo" }
          name   { "Terravivo updates" }
          type   { "Software" }
	  freqs  { "6 hours", "daily", "weekly" }
          primo  { "" }
          secundo{ "" }
          source { "" }
	    name  { "Terravivo update mirror in Los Angeles" }
	    domain{ "" }
	    method{ "ftp" }
	    file  { "/tv/htdocs/news/news19981025.html" }
	      src  { "/updates/42/news/news19981025.html" }
	    file  { "/tv/bin/swsearch" }
	      src  { "/updates/42/bin/swsearch"  }
	      post { "chmod 755 /tv/bin/swsearch" }
	      sum  { "50226 31 /tv/bin/swsearch"  }
	    file  { "/tv/bin/rasmol" }
	      src  { "/updates/42/bin/rasmol43"    }
	      post { "chmod 755 /tv/bin/rasmol4.3" }
	      sum  { "42901 31 /tv/bin/rasmol43"   }
	      post { "ln -s /tv/bin/rasmol43 /tv/bin/rasmol" }
	    ... other software, scripts, etc ...
          source { "" }
	    name  { "Metaphorics, LLC." }
	    domain{ "" }
	    method{ "ftp" }
	    ... file...
	  ... other sources ...
        ... other resources ...
      /*** end of terravivo update 42 ***/

    You'll note that the above is very EZ/CEX-oriented, essentially an
    object-property description (the first, unnamed property is the
    stringvalue).  It's not hard to see how the HTML/CGI interfaces can
    be written from such a description, the same goes for the makefiles
    but perhaps that's a bit trickier (Roger?!).  Note that "our" file
    /tv/genomes/h_pylori/h_pylori.fasta can be generated from tigr's
    GHP.seq.gz with the specified conv(ersion) method using gunzip and
    Outstanding issues include figuring out whether such a specification
    should dictate the method exactly (e.g., using ftp, gunzip, etc.)
    or would we be better off using a jake-like system with macros to
    do things like FTP(src,dst,hints), checksums, post-processing, etc.
    I like jake a lot, but if we're going to be on a stable platform,
    we might just as well download the actual makefiles (though that
    makes me nervous, too).

== ISSUES NEAR CONCENSUS ========================================


SD> [ prefer transparent background cells to white cells in tables ]
DW> OK.  The 2nd generation tables have transparent backgrounds.
    However, editable configuration fields should still have a white
    background, to make them distinctive, right?

[x]----- THE LOGO

SD> I think the logo is way to green/cyan
JB> the Metaphorics logo looks OK on my machines (perhaps it could
    be a bit darker).
SD> Does the attached gif look any better?
JB> Yes, your gif is better.  But the light part of the shadows still
    shows up as green/cyan when I think that the shadows should fade to
    transparent or neutral instead.  I've attached the one I used in the
    webpage I put together months ago.
DW> Jeff's right: Scott's logo looks better but needs to fade to background.
    BTW, on my machine, Jeff's logo isn't a transparent GIF.

    Scott, could you make an un-cyanized "200-size" logo which fades to the
    "sandy.gif" background?  This would be exclusively for use on the sandy
    background, call it something like "MetaSandyLogo200.gif"?

== SETTLED ISSUES ========================================

[x]----- THE NAME "Terravivo"

DW> "terravivo" is fine with me
JB> TerraVivo is as good a name as any I've heard yet.
YT> We got the domain name "" from InterNIC:
    > REFERENCE No.: 55256
    > REGISTRANT (Owner): Metaphorics LLC


DW> The background that we previously used (sand.gif) was a bit dark,
    making it hard to read black text, so I lightened it up and used
    that (sandy.gif).
JB> The lighter background looks good
ALL> We'll use "sandy.gif" as our web background.


JB> Does it matter whether we use http or ftp for downloads?
DW> No.  As I indicated, users/manager see the server domain, but the
    details (host, directory, protocol, etc.) are terravivo's problem,
    not theirs.  Terravivo can do anything it wants to get the job done.

== BOTTOM LINES ========================================

[ ] "Terravivo" will be the product name.  We'll probably make the
    domain do terravivo-specific things (like updating).
    We'll recommend the mount point /tv (and document things that way).

[ ] We'll use "sandy.gif" as our web background, "sand.gif" for accent.