From e2dd1219cb14537b5aca1a855e84cbe82f96cd4d Mon Sep 17 00:00:00 2001 From: Mike Taylor Date: Thu, 21 Sep 2006 15:44:12 +0000 Subject: [PATCH] Append --- archive/ui | 151 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 151 insertions(+) diff --git a/archive/ui b/archive/ui index 9799a82..b219049 100644 --- a/archive/ui +++ b/archive/ui @@ -223,3 +223,154 @@ area at the top?) in South America - evil bad people launch the meteor into space and disaster ensues" - Derek Tearne +From mike Thu Sep 21 13:41:36 2006 +X-VM-v5-Data: ([nil nil nil nil nil nil nil t nil] + ["4949" "Thursday" "21" "September" "2006" "14:18:09" "+0200" "Per M. Hansen" "perhans@indexdata.dk" nil "118" "Re: Target classifications" "^From:" nil nil "9" nil nil nil nil nil nil nil nil nil] + nil) +Return-path: +Envelope-to: mike@indexdata.com +Delivery-date: Thu, 21 Sep 2006 14:18:47 +0200 +Received: from localhost.localdomain [127.0.0.1] + by localhost.localdomain with POP3 (fetchmail-6.3.2) + for (single-drop); Thu, 21 Sep 2006 13:41:36 +0100 (BST) +Received: from user.indexdata.dk ([213.150.43.10] helo=[10.0.1.61]) + by bagel.indexdata.dk with esmtp (Exim 4.50) + id 1GQNVv-0002Os-Bq; Thu, 21 Sep 2006 14:18:47 +0200 +Message-ID: <45128301.1090208@indexdata.dk> +Organization: Index Data ApS +User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) +MIME-Version: 1.0 +References: <450FBF59.8270.00DD.0@sedubois.k12.in.us> <451126FB.8030005@indexdata.dk> <45112774.7070705@indexdata.dk> <17681.12470.646110.396726@localhost.localdomain> <451131CE.3040203@indexdata.dk> <17681.17678.192303.760970@localhost.localdomain> <45126053.701@indexdata.dk> <17682.31345.810933.890051@localhost.localdomain> +In-Reply-To: <17682.31345.810933.890051@localhost.localdomain> +X-SA-Do-Not-Run: Yes +X-SA-Exim-Connect-IP: 213.150.43.10 +X-SA-Exim-Rcpt-To: mike@indexdata.com, quinn@indexdata.dk +X-SA-Exim-Mail-From: perhans@indexdata.dk +X-SA-Exim-Scanned: No (on bagel.indexdata.dk); SAEximRunCond expanded to false +X-UIDL: 0'=!!8Nn!!m~^!!$+="! +Content-Type: text/plain; charset=ISO-8859-1; format=flowed +From: "Per M. Hansen" +To: Mike Taylor +CC: Sebastian Hammer +Subject: Re: Target classifications +Date: Thu, 21 Sep 2006 14:18:09 +0200 + + + +Mike Taylor skrev: +> Per M. Hansen writes: +> > > You can now see the work-in-progress at +> > > http://irspy.indexdata.com/ +> > +> > Look great, Mike. +> > +> > I have a few comments: +> +> Thanks for these. +> +> > * In the Add target screen I had envisioned a lot more fields for +> > entering data about the server. First of all we need a Name field. +> > Second it think we should have a section with additional info +> > about the target, like URL to hosting org. Email to technical +> > contact (that is the mail we use to send mails to when we +> > encounter a problem with the server), Username and password, Type +> > of library (probably a dropdown with, Academic, Public, Corporate, +> > Special, National, Education, Other) and Country. +> +> Yep, most or all of that fits into the ZeeRex record. The current +> version doesn't have any of it, because it's using the IRSpy ability +> to quietly add a new record as a side-effect of running the tests on a +> not-previously-known target; but when I do the proper "Add a target" +> page, it'll have a lot more spaces. Also, the option of uploading a +> pre-made ZeeRex record. +> +> > * In the display of the targets you should have room or at least +> > some way of showing this additional info. Maybe some kind of mouse +> > over or popup. +> +> Hadn't thought of those approaches -- I was just going to have a +> "[Details]" link. IIRC, mouseover is easy to do with compliant XHTML +> (which is what I use anyway) so maybe I'll try it that way. +> +> > * In the target display, eg. under R the display of non ASCII +> > characters goes wrong. +> +> Oh *%^$! Freakin' character-sets! :-) +> +> Thanks, I'll look into that. +> +> > Then I have some questions: +> > +> > * How are you going to handle targets that has (permanent) errors? +> > Will they be marked or excluded from the list? +> +> Open to discussion. The first question I suppose is what would count +> as "permanent" -- no response for six months? +> +In Z-Spy we contact the administrator if the target is down 3 times in a +row, which in praxis means 3 days in a row, and that has worked well +over the years. This has to be configurable of course. In Z-Spy, we do +not fall back to administrator/hostmaster/info@domain, but that is nice +idea. +> > * How are you going to handle email notification of technical +> > contact persons with targets that has permanent errors? +> +> Easily enough for targets whose ZeeRex records have a contact email in +> them! For others, I guess falling back to is the +> best we can do automatically? +> +> > * Have you thought about a statistics page like in Z-Spy? +> +> Patience, my pretty! +> +Ok, just checking :-) +> > * When added a target, can you handle targets with multiple +> > databases? How do you write the database names in the +> > inputbox? +> +> In ZeeRex terms, each target is a single database -- so a Z-server +> that has multiple databases would register each of them as a separate +> target that just happens to have the same host and port as its +> buddies. +> +Sounds OK, but wont you get the same problem as Z-Spy, where it is very +hard to display this target as one server with multiple databases under, +as in one line in the display? Wouldn't you need to have each database +on a new line and the user would then have to discover by her self that +say line 5, 6 and 7 is actually one server with different databases. +> > * When adding a new target do you have a check if the target is +> > there already, maybe registered with the IP instead of the +> > hostname? +> +> Nope. Do you think I should? +> +Yes, otherwise the database will get full of doubles. +> > * Should we get a designer to give the site an overhaul? +> +> Given how far over time (and so over budget!) we already are, I +> wouldn't have thought so. But once it's all working functionally, we +> can revisit that and figure out what we want to do with the cosmetics. +> +You are probably right. +> (What's wrong with it, anyway? Does it need a Hot Chick in the banner +> area at the top?) +> +My experience is that a nice design is essential for how the customer +evaluates the software. If it looks nice the software is also more +likely to be evaluated as high quality. Your design is not ugly or +anything but is obvious that is not something that has been spend a lot +of time on, but lets keep it that way for the time being. + +-- +Per +> _/|_ ___________________________________________________________________ +> /o ) \/ Mike Taylor http://www.miketaylor.org.uk +> )_v__/\ "In JP III, scientists recreate the actual dino killer meteorite +> from glassy fragments found near somewhere difficult to spell +> in South America - evil bad people launch the meteor into space +> and disaster ensues" - Derek Tearne +> +> +> + + -- 1.7.10.4