From: Petter W. <pet...@ya...> - 2004-06-17 06:14:50
|
Hi Carlos, Great work with the application! I see there's quite a long list of future ideas, here are some opinions on some of them: > #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? Anyway, personally I think it's a shame that the submission format uses the ISO-8859-1 encoding. It should be UTF-8 or UCS-2, that way comics from all over the world could be indexed. But that's not really our decision to make, the submission format uses ISO-8859-1, and that's it. If I'm not completely remembering wrong, it's only when you try to save your indexed comics in the submission format that Testimony forces you to use ISO-8859-1 characters. If you save in XML or something else, Testimony let's you use whatever characters you want, and also include newline and tab characters in the texts. I think that is a reasonable approach, and that we should not change anything. However, we could very well argue in the Tech forum for a change, that the submission format should use UCS-2 or UTF-8. I know that we've both done that on different occasions, but nothing has happened of course. 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. I think this is good because the different formats puts different restrictions on the data. > 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. > - 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? > - ProgressBar: > + Show ProgressBar in all time consuming events > (sort & import) ??? > + ProgressBar must show the correct progression > when available Good idea. > - 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? > - 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. > ...... > + 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. No one knows really what the OI will look like if it comes online again, but if we compare with the old OI there was (in my opinion) very large problems with data validation. There was none built in, and instead there was the system with reviews by editors. Editors had not read the formatting rules careful enough, and being only human, missed mistakes in the indices, causing a lot of unnecessary errors to be entered into the DB... We should instead have a system where the editing tools enforces the formatting rules that we have. The OI has no such support built in, and i doubt that Jon and the others will ever find time to write it. But Testimony could have it, and it could be added quite easily. The editing tool could enforce the formatting rules, pointing out the most common mistakes, and the editors could concentrate on reviewing the actual data being put into the system... > + 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. > + 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? > - 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. > + 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... > + 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... > - Multilanguage sequence type ??? > - Support Distribution format ??? Not sure I understand these two... > - 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... > - 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. Regards, Petter __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |