Thread: RV: [Testimony-devel] Testimony: v 1.2 status and ideas for the future versions

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hi Peter,

Here are my comments:

> > #PENDING BUGS#
> > - (Major)The ? simbol is not correctly recognised in the ISO-8859-1
> >   - GCD standard is ISO-88958-1 (ASCII). That coding doesn't 
> > supports the ?
> > simbol
> >   - ISO-8859-15 or UTF-8 should be used
>
> The actual symbol that was not part of the encoding was filtered away 
> somewhere before the mail reached me. What was it? Euro symbol?

Yes, it's the Euro symbol. I already asked in the Tech list some weeks ago,
and they said the same. That the format should be UTF-8 or ISO-8859-15. They
also pointed another option, that's convert directly the unknown symbol in
the euro.

> I think the application should be used in the following way: When 
> editing indices and saving them to the local hard drive, XML format 
> should be used.
> That format should handle all Unicode characters (I believe it does). 
> The more restrictive submission format should olnly be used when 
> exporting indices for submitting.

That's a good idea, I'll take a look at the code to see if that's what we're
doing now, if not I'll change that to use XML by default.

> > Version 1.3 - 1.5
>
> Here are some opinions on your idea for future improvements. I haven't 
> indexed in a long time, so I'm a little out of the loop, but here goes 
> anyway :)
>
> First of all, I still think that the most crucial functionality is to 
> be able to automatically submit indexed comics. That is of course hard 
> to code without some support from the GCDB coders (Jon and others), or 
> at least the OI up and running. But having said that, I think it's 
> important to remember that that is the "killer functionality" that 
> would make the Testimony application actually be used by more people.

I completelly agree with you, but until the OI is finished I don't think
that Jon will have enough time to give us support.

> > - Support to import/export/store covers
>
> This is a cool idea I think. Any ideas on how to solve it, 
> design-wise, in the application?

I've a couple ideas, we can discuss them when we arrive to that point.
Basically I've think to show the cover in the Issue Dialog and configure
what cover size do you want to download (if you want to do it). Another
feature would be some kind of cover gallery, but I think that will be
another feature.

> > - ProgressBar:
> >   + Show ProgressBar in all time consuming events (sort & import) ???
> >   + ProgressBar must show the correct progression when available
>
> Good idea.

First in the list :)

> > - XML:
> >   + Rewrite XML export code. Needs a better control in the code 
> > conversion
> > (?)
> >   + Detect if the information is valid when importing from an XML
> > - Detect when a series/issue is already imported
> >   + Show that issue different in the IssueSelectDialog
> >   + Show a warning before overwrite it (delete and import the new 
> > one or just overwrite ???)
>
> > - Error System:
> >   + More information. Add field support (redirect to the field and 
> > show some kind of warning in the field)
> >   + Redirect System.err to the errors table
> >     * Config a debug option. Show some information only if debug 
> > enabled.
> >     * Needs to implement a new tab for text information
> >     * Remove all the System.err and use the Error system
> >   + Add contextual menu to the errors panel
>
> I like the idea with an error system very much.
>
> Why bother with the system.err at all? I think a good approach would 
> be to remove all references to system.err and use the error system 
> throughout instead, if that is possible. But, like I said, I'm out of 
> the loop and might have forgotten something about how it works...
>
> The error system has great potential, I think. One thing that I missed 
> when I test-ran the application was the possibility to click on an 
> error and go to the location where the error is. This can be tricky of 
> course because there are a lot of different "locations" to go to - 
> fields etc. in the application but also text files and HTML pages 
> being imported...
>
> Also, I noted that errors that are the result of a failed import never 
> goes away. There should perhaps be a way of clearing the error list, 
> or better yet, some smart way of it being cleared automatically?

That's also in the high priority list. My planning is to recode all the
control errors part with a Logger and from that point  increment the
control. Now is possible to go directly to the sequence where the error is
detected, but I'm not happy with the way it's implemented.

> > - Menu:
> >   + Add changelog file and menu options to report errors, ask 
> > features,
>
> This one I like! A first implementation (that might very well prove 
> sufficient even in the long run) would be to use the BrowserLauncher 
> (or whatever it's
> called) to go to the Testimony bug report page.
>
> Later, we could perhaps add functionality for automatically attaching 
> logs, screen shots, etc. that would make our work easier. At the 
> moment, we do not generate such information, but we could make an 
> effort there.
>
> I think this feature is not so important yet, but will prove valuable 
> when people start to use the application.

Again I agree with you. I think that a first implementation would be to add
some menuitems that opens the internet browser to the correct page (as you
point). Maybe later I'll add a local changelog (Testimony should stay
offline as much as possible)

> > ......
> >   + Add validate option
> >     * Menu item
> >     * Config if validate info automatically before saving to file
> >     * Input info validation should be done in the Series, Issue and 
> > Sequence classes (Interface ?).
>
> This is a feature I think is quite important for Testimony, here we 
> could have an advantage over the traditional OI.

That's also a very important feature, but I think it should wait until the
error system is completelly done. We should also think what's the better way
to do it, and we're should be the validation code. Also it's very important
to define what kind of thinks will be validated and if they should be
configurable or not.

>
> >   + Add Print option
> >     * Options: full collection, current series, current issue, 
> > current sequence
> >     * Config internally as HTML.
> >     * Possibility to support style sheets to config the way the info 
> > is show
>
> This is not so important in my opinion. Maybe for printing out data 
> for review before submitting... But I think these feature can wait a bit.

That's low priority and very related with other points (see later)

> >   + Add search menu option
> >     * Search in the local database
> >     * Search in internet
>
> Cool idea, but necessary? The Internet DB is already searchable 
> through the GCD home page... I think we should maintain the interfaces 
> to the DB at a minimum so that we have as little to maintain as 
> possible if the online DB interface changes unexpectedly. At least 
> until we can get a stable, well specified interface to the online DB, 
> I think this could wait.
>
> Searching the local DB is interesting, not so useful at least not for 
> the way I would use it. I would not keep a lot of data in the local 
> DB, just the comic I'm currently indexing. After submitting it, I 
> would not use the local DB for a searchable database. Maybe you see a 
> different use case?

The local search is also low priority and very related with other points
(see later). On the other hand I think that the search is the GCD site is
important. If the user can search from inside the tool for the serie or
issue that he wants to import, I think will be more confortable and
intuitive than not looking for some kind of code in the url.

> > - GUI enhancements:
> >   + Autocomplete comboboxes:
> >     * Should be possible to indicate case sensitive or not case 
> > sensitive
>
> Here's an idea: Auto-completion could recognize text case-unsensitive, 
> but complete it case-sensitive, if you understand what I mean... If I 
> enter "stan", the auto completion could suggest "Stan Lee", and if I 
> select that option "Stan Lee" should be entered, not "stan Lee".
>
> Even though I write large parts of the auto-completion, I don't 
> remember how it works today.

That's exactly what I meant. I would like to do that for the next release.

> >   + Generate keydate from the date info (and viceversa). If doesn't 
> > match show error.
>
> The "If doesn't match show error" part seems like an idea for the 
> validation I think...

I agree that the error part should be in the validation system. The idea is
that should be enought writing only one info (cover date or key date) and
the system will create the other.

> >   + Add theme support for the Metal Look & Feel
> >     * See support in Java 1.5
> >     * See how to add possibility to be configured by the user (store 
> > in registry or config file ???)
> >
> > Other ideas
> > - Increment the functionality to support user collection
> >   + Comic state, location, number of copies, valoration, user notes, 
> > ...
>
> Here you are definitely thinking of a different use case. I've mostly 
> been thinking that Testimony would be used for indexing, period. Not 
> keeping a local database.
>
> If we want to use Testimony for keeping a local database, I think we 
> would have to improve the way data is stored to disk. Perhaps it would 
> make more sense to use a proper SQL-enable DB engine instead of the 
> current flora of storage formats...

That's really a big modification (I think could go for the version 2). The
idea is use Testimony as something more than and offline indexing tool, but
also as a Comic Organizer/DataBase. I think that that should be configurable
and the user should be able to select if wants to work in "indexing mode" or
"collector mode". As I say it's a big change and I want to talk about that
before doing anything. But again, that should go for version 2 :)

> > - Multilanguage sequence type ???
> > - Support Distribution format ???
>
> Not sure I understand these two...

With Multilanguage sequence type I'm talking about the possibility to show
the sequence genre in the local language. The distribution format is
something that is talked about in the GCD documentation, but I cannot really
remember where.

> > - A help system where it would be possible to get quotes from the 
> > format file about
> >   what should go into the various database fields
>
> I like this one a lot. Has been up for discussion before if I remember 
> correctly. Could be connected to the error and the validation systems, 
> so that the user can get instant feedback on his mistakes from the 
> official documents.
>
> > - Multilanguage tooltips for fields
> > - Include help as an HTML frame browser
> >   + Will need translation
>
> Good point with the translation. Makes it more complex...

Really complex, that's because I'm delaying it :)

> > - Undo option ???
>
> Very good idea. There are standard solutions for implementing undo I 
> think.
> This one is a really nice feature that, in my opinion, should be in 
> every serious application... Not crucial, but nice.

I'm not sure that's not crucial. If you're indexing a serie and by mistake
you delete that.... I known that we're asking for confirmation, but anyway I
think that we should increment the security in that part. Not only and undo
feature, but maybe somekind of autosave every x minutos in a temp file or
something like that would be good. But I really have no idea how to do the
undo think. I'll try to find documentation about that.

So, after all that discussion, here is a more explicit version prevision. I
think that should be something like that:

Version 1.2 (TODO) [Middle July]
- Finish code reorganization
- Put home page in the new module
- Better icons for the series, issue and sequences nodes
- Code CheckStyle
- Finish buil.xml
- (Test)Bug with Sort/Collapse options

Version 1.2.5 [October]
- ProgressBar (needs code reestructuration):
  + Show ProgressBar in all time consuming events (sort & import) ???
  + ProgressBar must show the correct progression when available
- Rewrite the import code (site and XML) to support:
  + Detect when a series/issue is already imported
    - Show that issue different in the IssueSelectDialog
    - Show a warning before overwrite it (delete and import the new one or
just overwrite ???)
- Error System:
  + More information. Add field support (redirect to the field and show some
kind of warning in the field)
  + Redirect System.err to the errors table
    - Config a debug option. Show some information only if debug enabled.
    - Needs to implement a new tab for text information
    - Remove all the System.err and use the Error system
  + Add contextual menu to the errors panel
- Preferences Dialog:
  + Possibility to reset to default values
- GCDSiteIssueFormatReader: Modify code to use patterns
- GUI enhancements:
  + Autocomplete comboboxes:
    - Should be possible to indicate case sensitive or not case sensitive
  + Generate keydate from the date info (and viceversa). If doesn't match
show error.

Version 1.3 [January]
- Menu:
  + Undo option
  + Add validate option
    - Menu item
    - Config if validate info automatically before saving to file
    - Input info validation should be done in the Series, Issue and Sequence
classes (Interface ?).
    - Detect if the information is valid when importing from an XML, TXT or
GCD
  + Add changelog file and menu options to report errors, ask features,
......
- Support to import/export/store covers
  + Config is you want to import the cover
  + Config the importing cover size by default
(Small(x1)/Medium(4x)/High(16x) Resolution)
  + Cover can be show in the Issue information
  + Support for multiple/variant covers (GCD would do it in the future)
  + Internal cover gallery
- Sequence genre in local language

Version 1.4 [Easter 2005]
- Menu:
  + Add search menu option
    - Search in the local database
    - Search in internet
  + Add Print option
    - Options: full collection, current series, current issue, current
sequence
    - Config internally as HTML.
    - Possibility to support style sheets to config the way the info is show
  + Add HTML Export option (use the same code to print)
- GUI enhancements:
  + Add theme support for the Metal Look & Feel
    - See support in Java 1.5
    - See how to add possibility to be configured by the user (store in
registry or config file ???)
  + New Themes with Java 1.5
    - Ocean
    - XAWT (Only X11)
- Help system (firstly only in english but thinking it'll by multilanguage):
  + A help system where it would be possible to get quotes from the format
file about what should go into the various database fields
  + Multilanguage tooltips for fields
  + Include help as an HTML frame browser

Version 2.0 [Summer 2005?]
- Increment the functionality to support user collection
  + Comic state, location, number of copies, valoration, user notes, ...

What do you think? I'll go on developing by myself, but if you, or Mark,
have enough free time at some time to do some of the new features, tell me
and I'll be more than happy :)

About the 1.2.5 version: I think that's not really a version, but only some
intermediate point to finish, fixing and enhancing some allready existing
features. That remembers me that we've not touch the possibility to do new
versions more often. I think that, for example we could go with something
like 1.2.1 (finish the progress bar work); 1.2.2 (finish the error system);
.... and so on. That will be the same for other versions, were we could go
incrementing versions as we finish new features or fixings. In that way we
remove the beta status.

Regards,
Carlos.

Thread: RV: [Testimony-devel] Testimony: v 1.2 status and ideas for the future versions

testimony-devel