archive/ui

   1 From perhans@indexdata.dk  Thu Sep 21 11:14:39 2006
   2 X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
   3         ["5714" "Thursday" "21" "September" "2006" "11:50:11" "+0200" "Per M. Hansen" "perhans@indexdata.dk" "<45126053.701@indexdata.dk>" "149" "Re: Target classifications" "^From:" nil nil "9" nil nil nil nil nil nil nil nil nil]
   4         nil)
   5 Return-Path: <perhans@indexdata.dk>
   6 X-Original-To: mike@localhost
   7 Delivered-To: mike@localhost
   8 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
   9         by localhost.localdomain (Postfix) with ESMTP id D7051ABB25
  10         for <mike@localhost>; Thu, 21 Sep 2006 11:14:39 +0100 (BST)
  11 Envelope-to: mike@indexdata.com
  12 Delivery-date: Thu, 21 Sep 2006 11:50:47 +0200
  13 Received: from localhost.localdomain [127.0.0.1]
  14         by localhost.localdomain with POP3 (fetchmail-6.3.2)
  15         for <mike@localhost> (single-drop); Thu, 21 Sep 2006 11:14:39 +0100 (BST)
  16 Received: from user.indexdata.dk ([213.150.43.10] helo=[10.0.1.61])
  17         by bagel.indexdata.dk with esmtp (Exim 4.50)
  18         id 1GQLCh-0000nn-JE; Thu, 21 Sep 2006 11:50:47 +0200
  19 Message-ID: <45126053.701@indexdata.dk>
  20 Organization: Index Data ApS
  21 User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
  22 MIME-Version: 1.0
  23 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>
  24 In-Reply-To: <17681.17678.192303.760970@localhost.localdomain>
  25 X-SA-Do-Not-Run: Yes
  26 X-SA-Exim-Connect-IP: 213.150.43.10
  27 X-SA-Exim-Rcpt-To: mike@indexdata.com, quinn@indexdata.dk
  28 X-SA-Exim-Mail-From: perhans@indexdata.dk
  29 X-SA-Exim-Scanned: No (on bagel.indexdata.dk); SAEximRunCond expanded to false
  30 X-UIDL: %l>"!C@~"!b0,#!o@V"!
  31 From: "Per M. Hansen" <perhans@indexdata.dk>
  32 To: Mike Taylor <mike@indexdata.com>
  33 CC: Sebastian Hammer <quinn@indexdata.dk>
  34 Subject: Re: Target classifications
  35 Date: Thu, 21 Sep 2006 11:50:11 +0200
  36 X-StripMime: Non-text section removed by stripmime
  37 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
  38
  39
  40
  41 Mike Taylor skrev:
  42 > Per M. Hansen writes:
  43 >
  44 >>>> As you can see there are people out there who are waiting for
  45 >>>> IRSpy. :-) How is the work progeressing?
  46 >>>>
  47 >>> Looking quite nice.  I'll put a copy of the web interface up on
  48 >>> test so you can see how it's coming along.
  49 >>>
  50 >>
  51 >> Sounds great, looking forward to see it.
  52 >>
  53 >
  54 > You can now see the work-in-progress at
  55 >       http://irspy.indexdata.com/
  56 >
  57 > If you get Unknown Host for that address, it's because the DNS change
  58 > hasn't propagated to you yet.  Until then, make an entry in your local
  59 > hosts table pointing the hostname to 213.150.43.14 (test).
  60 >
  61 > Of course, be aware that the UI is not finished!  The biggest gap at
  62 > the moment is that you can't see the results of any of the tests (at
  63 > least, not without reading the Apache logs :-)
  64 Look great, Mike.
  65
  66  I have a few comments:
  67
  68     * In the Add target screen I had envisioned a lot more fields for
  69       entering data about the server. First of all we need a Name field.
  70       Second it think we should have a section with additional info
  71       about the target, like URL to hosting org. Email to technical
  72       contact (that is the mail we use to send mails to when we
  73       encounter a problem with the server), Username and password, Type
  74       of library (probably a dropdown with, Academic, Public, Corporate,
  75       Special, National, Education, Other) and Country.
  76     * In the display of the targets you should have room or at least
  77       some way of showing this additional info. Maybe some kind of mouse
  78       over or popup.
  79     * In the target display, eg. under R the display of non ASCII
  80       characters goes wrong.
  81
  82 Then I have some questions:
  83
  84     * How are you going to handle targets that has (permanent) errors?
  85       Will they be marked or excluded from the list?
  86     * How are you going to handle email notification of technical
  87       contact persons with targets that has permanent errors?
  88     * Have you thought about a statistics page like in Z-Spy?
  89     * When added a target, can you handle targets with multiple
  90       databases? How do you write the database names in the inputbox?
  91     * When adding a new target do you have a check if the target is
  92       there already, maybe registered with the IP instead of the hostname?
  93     * Should we get a designer to give the site an overhaul?
  94
  95 --
  96 Per
  97
  98
  99
 100 --- StripMime Report -- processed MIME parts ---
 101 multipart/alternative
 102   text/plain (text body -- kept)
 103   text/html
 104 ---
 105
 106
 107 From mike@miketaylor.org.uk  Thu Sep 21 12:41:37 2006
 108 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
 109         ["3640" "Thursday" "21" "September" "2006" "12:41:37" "+0100" "Mike Taylor" "mike@indexdata.com" nil "90" "Re: Target classifications" "^From:" nil nil "9" nil nil nil nil nil nil nil nil nil]
 110         nil)
 111 Return-Path: <mike@miketaylor.org.uk>
 112 X-Original-To: mike
 113 Delivered-To: mike@miketaylor.org.uk
 114 Received: by localhost.localdomain (Postfix, from userid 1000)
 115         id E282CABB26; Thu, 21 Sep 2006 12:41:37 +0100 (BST)
 116 MIME-Version: 1.0
 117 Content-Type: text/plain; charset=us-ascii
 118 Content-Transfer-Encoding: 7bit
 119 Message-ID: <17682.31345.810933.890051@localhost.localdomain>
 120 In-Reply-To: <45126053.701@indexdata.dk>
 121 References: <450FBF59.8270.00DD.0@sedubois.k12.in.us>
 122         <451126FB.8030005@indexdata.dk>
 123         <45112774.7070705@indexdata.dk>
 124         <17681.12470.646110.396726@localhost.localdomain>
 125         <451131CE.3040203@indexdata.dk>
 126         <17681.17678.192303.760970@localhost.localdomain>
 127         <45126053.701@indexdata.dk>
 128 X-Mailer: VM 7.19 under Emacs 21.4.1
 129 From: Mike Taylor <mike@indexdata.com>
 130 To: "Per M. Hansen" <perhans@indexdata.dk>
 131 Cc: Sebastian Hammer <quinn@indexdata.dk>
 132 Subject: Re: Target classifications
 133 Date: Thu, 21 Sep 2006 12:41:37 +0100
 134
 135 Per M. Hansen writes:
 136  > > You can now see the work-in-progress at
 137  > >    http://irspy.indexdata.com/
 138  >
 139  > Look great, Mike.
 140  >
 141  >  I have a few comments:
 142
 143 Thanks for these.
 144
 145  >     * In the Add target screen I had envisioned a lot more fields for
 146  >       entering data about the server. First of all we need a Name field.
 147  >       Second it think we should have a section with additional info
 148  >       about the target, like URL to hosting org. Email to technical
 149  >       contact (that is the mail we use to send mails to when we
 150  >       encounter a problem with the server), Username and password, Type
 151  >       of library (probably a dropdown with, Academic, Public, Corporate,
 152  >       Special, National, Education, Other) and Country.
 153
 154 Yep, most or all of that fits into the ZeeRex record.  The current
 155 version doesn't have any of it, because it's using the IRSpy ability
 156 to quietly add a new record as a side-effect of running the tests on a
 157 not-previously-known target; but when I do the proper "Add a target"
 158 page, it'll have a lot more spaces.  Also, the option of uploading a
 159 pre-made ZeeRex record.
 160
 161  >     * In the display of the targets you should have room or at least
 162  >       some way of showing this additional info. Maybe some kind of mouse
 163  >       over or popup.
 164
 165 Hadn't thought of those approaches -- I was just going to have a
 166 "[Details]" link.  IIRC, mouseover is easy to do with compliant XHTML
 167 (which is what I use anyway) so maybe I'll try it that way.
 168
 169  >     * In the target display, eg. under R the display of non ASCII
 170  >       characters goes wrong.
 171
 172 Oh *%^$!  Freakin' character-sets!  :-)
 173
 174 Thanks, I'll look into that.
 175
 176  > Then I have some questions:
 177  >
 178  >     * How are you going to handle targets that has (permanent) errors?
 179  >       Will they be marked or excluded from the list?
 180
 181 Open to discussion.  The first question I suppose is what would count
 182 as "permanent" -- no response for six months?
 183
 184  >     * How are you going to handle email notification of technical
 185  >       contact persons with targets that has permanent errors?
 186
 187 Easily enough for targets whose ZeeRex records have a contact email in
 188 them!  For others, I guess falling back to <hostmaster@domain> is the
 189 best we can do automatically?
 190
 191  >     * Have you thought about a statistics page like in Z-Spy?
 192
 193 Patience, my pretty!
 194
 195  >     * When added a target, can you handle targets with multiple
 196  >       databases? How do you write the database names in the
 197  >       inputbox?
 198
 199 In ZeeRex terms, each target is a single database -- so a Z-server
 200 that has multiple databases would register each of them as a separate
 201 target that just happens to have the same host and port as its
 202 buddies.
 203
 204  >     * When adding a new target do you have a check if the target is
 205  >       there already, maybe registered with the IP instead of the
 206  >       hostname?
 207
 208 Nope.  Do you think I should?
 209
 210  >     * Should we get a designer to give the site an overhaul?
 211
 212 Given how far over time (and so over budget!) we already are, I
 213 wouldn't have thought so.  But once it's all working functionally, we
 214 can revisit that and figure out what we want to do with the cosmetics.
 215
 216 (What's wrong with it, anyway?  Does it need a Hot Chick in the banner
 217 area at the top?)
 218
 219  _/|_    ___________________________________________________________________
 220 /o ) \/  Mike Taylor    <mike@indexdata.com>    http://www.miketaylor.org.uk
 221 )_v__/\  "In JP III, scientists recreate the actual dino killer meteorite
 222          from glassy fragments found near somewhere difficult to spell
 223          in South America - evil bad people launch the meteor into space
 224          and disaster ensues" - Derek Tearne
 225
 226 From mike  Thu Sep 21 13:41:36 2006
 227 X-VM-v5-Data: ([nil nil nil nil nil nil nil t nil]
 228         ["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]
 229         nil)
 230 Return-path: <perhans@indexdata.dk>
 231 Envelope-to: mike@indexdata.com
 232 Delivery-date: Thu, 21 Sep 2006 14:18:47 +0200
 233 Received: from localhost.localdomain [127.0.0.1]
 234         by localhost.localdomain with POP3 (fetchmail-6.3.2)
 235         for <mike@localhost> (single-drop); Thu, 21 Sep 2006 13:41:36 +0100 (BST)
 236 Received: from user.indexdata.dk ([213.150.43.10] helo=[10.0.1.61])
 237         by bagel.indexdata.dk with esmtp (Exim 4.50)
 238         id 1GQNVv-0002Os-Bq; Thu, 21 Sep 2006 14:18:47 +0200
 239 Message-ID: <45128301.1090208@indexdata.dk>
 240 Organization: Index Data ApS
 241 User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
 242 MIME-Version: 1.0
 243 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>
 244 In-Reply-To: <17682.31345.810933.890051@localhost.localdomain>
 245 X-SA-Do-Not-Run: Yes
 246 X-SA-Exim-Connect-IP: 213.150.43.10
 247 X-SA-Exim-Rcpt-To: mike@indexdata.com, quinn@indexdata.dk
 248 X-SA-Exim-Mail-From: perhans@indexdata.dk
 249 X-SA-Exim-Scanned: No (on bagel.indexdata.dk); SAEximRunCond expanded to false
 250 X-UIDL: 0'=!!8Nn!!m~^!!$+="!
 251 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 252 From: "Per M. Hansen" <perhans@indexdata.dk>
 253 To: Mike Taylor <mike@indexdata.com>
 254 CC: Sebastian Hammer <quinn@indexdata.dk>
 255 Subject: Re: Target classifications
 256 Date: Thu, 21 Sep 2006 14:18:09 +0200
 257
 258
 259
 260 Mike Taylor skrev:
 261 > Per M. Hansen writes:
 262 >  > > You can now see the work-in-progress at
 263 >  > >  http://irspy.indexdata.com/
 264 >  >
 265 >  > Look great, Mike.
 266 >  >
 267 >  >  I have a few comments:
 268 >
 269 > Thanks for these.
 270 >
 271 >  >     * In the Add target screen I had envisioned a lot more fields for
 272 >  >       entering data about the server. First of all we need a Name field.
 273 >  >       Second it think we should have a section with additional info
 274 >  >       about the target, like URL to hosting org. Email to technical
 275 >  >       contact (that is the mail we use to send mails to when we
 276 >  >       encounter a problem with the server), Username and password, Type
 277 >  >       of library (probably a dropdown with, Academic, Public, Corporate,
 278 >  >       Special, National, Education, Other) and Country.
 279 >
 280 > Yep, most or all of that fits into the ZeeRex record.  The current
 281 > version doesn't have any of it, because it's using the IRSpy ability
 282 > to quietly add a new record as a side-effect of running the tests on a
 283 > not-previously-known target; but when I do the proper "Add a target"
 284 > page, it'll have a lot more spaces.  Also, the option of uploading a
 285 > pre-made ZeeRex record.
 286 >
 287 >  >     * In the display of the targets you should have room or at least
 288 >  >       some way of showing this additional info. Maybe some kind of mouse
 289 >  >       over or popup.
 290 >
 291 > Hadn't thought of those approaches -- I was just going to have a
 292 > "[Details]" link.  IIRC, mouseover is easy to do with compliant XHTML
 293 > (which is what I use anyway) so maybe I'll try it that way.
 294 >
 295 >  >     * In the target display, eg. under R the display of non ASCII
 296 >  >       characters goes wrong.
 297 >
 298 > Oh *%^$!  Freakin' character-sets!  :-)
 299 >
 300 > Thanks, I'll look into that.
 301 >
 302 >  > Then I have some questions:
 303 >  >
 304 >  >     * How are you going to handle targets that has (permanent) errors?
 305 >  >       Will they be marked or excluded from the list?
 306 >
 307 > Open to discussion.  The first question I suppose is what would count
 308 > as "permanent" -- no response for six months?
 309 >
 310 In Z-Spy we contact the administrator if the target is down 3 times in a
 311 row, which in praxis means 3 days in a row, and that has worked well
 312 over the years. This has to be configurable of course. In Z-Spy, we do
 313 not fall back to administrator/hostmaster/info@domain, but that is nice
 314 idea.
 315 >  >     * How are you going to handle email notification of technical
 316 >  >       contact persons with targets that has permanent errors?
 317 >
 318 > Easily enough for targets whose ZeeRex records have a contact email in
 319 > them!  For others, I guess falling back to <hostmaster@domain> is the
 320 > best we can do automatically?
 321 >
 322 >  >     * Have you thought about a statistics page like in Z-Spy?
 323 >
 324 > Patience, my pretty!
 325 >
 326 Ok, just checking :-)
 327 >  >     * When added a target, can you handle targets with multiple
 328 >  >       databases? How do you write the database names in the
 329 >  >       inputbox?
 330 >
 331 > In ZeeRex terms, each target is a single database -- so a Z-server
 332 > that has multiple databases would register each of them as a separate
 333 > target that just happens to have the same host and port as its
 334 > buddies.
 335 >
 336 Sounds OK, but wont you get the same problem as Z-Spy, where it is very
 337 hard to display this target as one server with multiple databases under,
 338 as in one line in the display? Wouldn't you need to have each database
 339 on a new line and the user would then have to discover by her self that
 340 say line 5, 6 and 7 is actually one server with different databases.
 341 >  >     * When adding a new target do you have a check if the target is
 342 >  >       there already, maybe registered with the IP instead of the
 343 >  >       hostname?
 344 >
 345 > Nope.  Do you think I should?
 346 >
 347 Yes, otherwise the database will get full of doubles.
 348 >  >     * Should we get a designer to give the site an overhaul?
 349 >
 350 > Given how far over time (and so over budget!) we already are, I
 351 > wouldn't have thought so.  But once it's all working functionally, we
 352 > can revisit that and figure out what we want to do with the cosmetics.
 353 >
 354 You are probably right.
 355 > (What's wrong with it, anyway?  Does it need a Hot Chick in the banner
 356 > area at the top?)
 357 >
 358 My experience is that a nice design is essential for how the customer
 359 evaluates the software. If it looks nice the software is also more
 360 likely to be evaluated as high quality. Your design is not ugly or
 361 anything but is obvious that is not something that has been spend a lot
 362 of time on, but lets keep it that way for the time being.
 363
 364 --
 365 Per
 366 >  _/|_  ___________________________________________________________________
 367 > /o ) \/  Mike Taylor    <mike@indexdata.com>    http://www.miketaylor.org.uk
 368 > )_v__/\  "In JP III, scientists recreate the actual dino killer meteorite
 369 >        from glassy fragments found near somewhere difficult to spell
 370 >        in South America - evil bad people launch the meteor into space
 371 >        and disaster ensues" - Derek Tearne
 372 >
 373 >
 374 >
 375
 376