[KPhotoAlbum] a working photo interface

Heinz Kohl kohl at informatik.uni-stuttgart.de
Mon Feb 19 15:42:14 GMT 2007


I was unexpectedly absent for a week, far off Internet.
In the meantime, the situation has changed for me.
I tried to update my KPA data bank and resigned.
First I tried to install 3.0 to see what's new - first try: missing a packet;
second try: download and install - but now missing another packet far away in 
the net.

Now I'm implementing a prototype edit machine, working name 'pico'.
Purpose:
- prototype to evaluate potential human-machine interfaces for KPA data edit
- prototype for a Mozilla Firefox 2.0 Application working on modest size 
albums (up to a 2000 photos) for all systems with Firefox, which is
  - making KPA index data usable for foreign systems without KPA
  - enhancing the KPA edit: more easy, faster, more flexible
- edit study: how and which add-ons are may be valuable to add 
- edit and spin off special presentations going over the possibilities of a 
mass archive management (a too far goal, but: professional presentations are 
having about 75 slides, to prepare one presentation may take months of work, 
every presentation has an original character)
  while
- loosely coupling such presentations to KPA
- evaluating possible additional features for KPA
- starting point for student work in the summer term.
  and, last not least,
- to demonstrate my point of view

The actual state could be demonstrated, the base functionality is visible, 
worked out and working (o.k., the presentation frame is empty at the moment, 
and changes aren't written).
But I think, I will do best to safe the time to explain, what's working - 
'pico 0.00' will be work in a week including (only) all base features (fast 
and visible category values differing for photo selection and value setting; 
rapid position setting; some sorting mechanisms; an additional selection 
mechanism; an edit environment including change remarking for edit 
tracing/foreign editors; basic suggestions for a more complex description 
environment).
Because of that, I'll think it would be best not to show the actual state, but 
version 0.00.
In the meanwhile I'll try to get a limited web address for restricted web 
access to this concept.

Am Montag 12 Februar 2007 10:37 schrieb Tero Tilus:
> 2007-02-09 08:08, Shawn Willden:
> > KPA handles very nicely the specific case that you started with --
> > scan batch numbers.
>
> I have been wondering that too, but what if it was scan _sequence_
> numbering he was talking about, bot scan batch id?

'scan batch number'?
No, if you're meaning this in the usual sense.
I was thinking just about the consecutive numbering generated by the scanner, 
and was using the same numbering over all scans (but in one single scan I've 
scanned 1 to ~8 pictures).

KPA 2.2 or is it a KPA 3.0 feature?
For my prototype it is setting up a big problem to cope with more than a very 
modest number of category values. In the moment I've only ~200, but that's 
filling 1/3 of a 1600x1200 screen, and for a good overview while editing it 
is necessary to see all - at least all relevant - remarks at a glance and at 
the same place as before. It's disturbing, when it is necessary to move or 
change the window to have a full view.
A program with good user interface has to work as a transparent window for the 
ideas of the user, after a short time the interface itself should work 
transparently like an ordinary window.
The set of category values is to be reduced to the set necessary to document 
the photos - on the other side, every category value valuable for documenting 
a photo collection has to be taken.
Restricting this set painfully  to the values necessary to find a photo isn't 
the right way, I think. I'm glad about every doc remark on an old photo, 
which was helpful to categorize a photo.

>
> > If you can describe actual, useful scenarios that KPA can't
> > presently handle, then you'll see more interest in addressing those
> > limitations.
>
> I think it's more about ability to describe than about scenarios
> versus abstractions.  ;)

It's not at all the theoretical possibility to do the work -
first:    it is the practical ease to do it
second: the method to do it should reflect a natural way to do it in a best 
possible way
   e.g.: date/time - a very complex object with showing manifolds of facets, 
all of them more or less obvious. It will be completely impossible to map all 
these facets in a closed manner. A point on a line may be exactly the right 
view in one case, an interval in an other. But these interpretations may set 
up pure information noise in other cases.
   A simple and obviously constructed example: 
   KPA would need four categories for "birthday" - day, month, year, weekday -
   just to look for 
   (1) all persons with birthday in this week
   (2) all persons born on a sunday
   After that, to do that for the day of death will set up the same problem

   O.K., KPA is no data bank.

   But for the simpler case 'data of photo generation' the KPA date/time could 
be of even less usability in real cases.
   I'll explain this with my prototype.
   KPA has date/time, I can't hide it, I would need it bitterly, but trying to 
use date/time in the original sense is setting up nothing but chaos.
   O.K., I could add four additional categories: year, month, day, special 
events, and groups of them, feeling soon like Laokoon.
   And every user has to learn to distinguish between these time categories 
and the KPA time, even in the lucky case, when he was knowing 'the picture 
was taken 30.10.1943', had not found the picture in the category 
'Allerseelen', and I 'may have been taken perhaps in 1939-1945, I'm sure, 
late in october or in the first november days'.
It could be worse.
I could have seen 30.10., marked Allerseelen, only the picture is showing 
18:30, I had estimated the year to 1936 to 1941, and he could look for 1943, 
late october, 18 o'clock.

H. Kohl   
           



More information about the Kphotoalbum mailing list