Hi there,
I still think that AEM is the very best ebook management SW at this moment. However it needs overhaul of SEARCH and GENRE features.
Here are few suggestions:
1) currently the management of the PARENT/CHILD relationship between GENRES is extremely difficult.
First, it has to be done "manually" - each genre has to be opened separately and parental genre selected from a list of genres. Even worse than that - the parental genre list is not sorted alphabetically but instead randomly making it useless in practical situations of having ~1000 genres. Typing the parental genre does not work either since only the first letter selects a genre which is not normally the one we want as a parental genre.
Second, it has to be done genre-by-genre instead of multiple genres at once (in one operation).
My proposal: I think drag-and-drop approach is the best here:
a) there should be possibility to select several genres at once (e.g. CTRL and Mouse-Click)
b) by dragging the selected genres and dropping them onto a parental genre makes all of the selected genres children of the parent genre.
2) there should be a SIMPLE mechanism for MERGING two or more genres into one (i.e. several selected genres are combined into a new one with automatic deleting of the old selected genres - the newly created genre accepts all the books from the old genres - or several genres are combined int one of the existing genre). Drag-and-drop approach could also be applied here.
3) there should be a BATCH mechanism to edit GENRE names (e.g. for all genres having "--" create multiple genres from the single genre string by decomposing it into several genres)
4) SEARCH needs to be extended to multiple fields/columns not just title or author name. Also it needs to support COMPLEX queries by MIXING several fields/columns in one query.
e.g. (GENRE="programming languages" AND Title-contains "C#" AND YEAR >2005 AND Tags="ToRead") OR (GENRE="programming languages" AND Title-contains "Java" AND YEAR >2001)
5) Search box has to be significantly WIDENED (currently it is too short) in order to support complex queries.
6) There should be search HISTORY, or possibility to SAVE frequent queries, thus making possible to query the database by selecting one of saved queries.
7) There should be possibility to disable results-as-you-type feature which significantly increases processor load. Instead results should be displayed only after pressing a SEARCH button after the query string is completely typed.
And finally my favorite feature:
---------------------------------
8) in relation to both SEARCH and GENRE features there should be a GENRE SEARCH mechanism which presents several (exact number to be left in user configuration) GENRES with the largest number of books. On the left of each genre name there should be a check box for selection and on the right the number of books having that particular genre. By clicking on the corresponding check boxes the mechanism should display next few genres which are present among books which have the checked genre selected.
E.g. the largest genre is "Programming languages" and it contains 345 books. When one clicks check box for the genre additional genres are automatically displayed. These genres represent additional genres which have books with checked genre (e.g. "Programming languages"). Thus these new genres might be for example "JAVA", "C++", "Web services"... all depending on particular database. Each additional genre has check box (for selection) and number of books having that particular genre AND all the previously selected genres during the process of finding the most appropriate book list.
IMPORTANT: This mechanism should NOT rely on the parent-child relationship among genres but instead on the processor consuming procedure of SEARCHING additional genres for one selected genre! I.e. this procedure should find all the extra genres for one selected genre + find the number of books for each extra genre.
This feature would significantly improve usability of GENRE browsing when one has large number of genres.
best regards from the Balkans
BalkanBear,
Thanks for your review and great suggestions!
Do you think it will be usable if instead of Genres tree we realize the one-level Genres list (with easy sort, search) and an opportunity to filter library by 2 or more genres at once? E.g. filter "Children + Adventures" will show only adventure books for children
First, I do not find parent-child relationship between genres very usable at this moment. Thus as far as I am concerned you could remove it and implement one-level genre list. However that would be INCOMPATIBLE change and you might have problems when upgrading SW - the old databases could not be imported easily into the new one! Some people might have spent a lot of time to build parent-child relationship between numerous genres and they would not be pleased if they find that they either cannot import their old databases into new SW or if they lose info during the upgrade.
Second, I do not find any reason why you should limit the number of genres to be searched -> you should accept ANY number of genres when searching/querying the database. Therefore your proposal seems reasonable to me.
ADDITIONAL PROPOSAL:
----------------------
9) You should also implement parser of REGULAR EXPRESSIONS for all types of searches. That is to say the parser should apply to all kind of strings - those that are part of either TITLE or AUTHOR or GENRE or YEAR etc...
I am aware that features 8) and 9) are processor consuming features (they increase the processor load) but considering that the processor peaks are TEMPORARY for this kind of SW (they occur only during queries) it is a very good trade to have a few processor load peaks for GOOD resulting reports on the database queries. My point is -> SEARCH engine is the feature that gives this kind of SW its power - less capable search engine in a database means less usable SW. You should concentrate on extending the power of SEARCH and GENRE features of your SW. Thus if you either extend SEARCH box or implement feature 8) or both above there should be no limit on the number of genres searched.
best regards/ Igor, Croatia
Thanks Igor, it seems that it would be useful to add an advanced Search/Filter tool. Could you please advise (describe or draw) how to inbuid such a tool in current Alfa interface?
As regards interface I would rather have more powerful TEXT based search engine than less powerful GUI based interface -> if you provide complex search with multiple field names + RegEx support (very important!) + support for Boolean operators + option to save queries in a history list all that within a simple text base interface I wouldn't care for GUI alternative. You could look into an example of powerful database SW -> WhereIsIt (http://www.whereisit-soft.com/) - it provides free (database reading) and shareware (database creation) versions. However both versions have powerful search capabilities. Please look into this SW for example on SEARCH interface.
I would also like to draw your attention to something else -> you have to have a TARGET VISION on how should your SW look like if made the best, with all possibilities and features in the future.
If there is a lack on this target vision then you find yourself in dangerous situations of removing existing features thus having incompatible upgrades or even worse finding new features very hard to implement into existing SW frame.
For example, if I know that the target vision of the SW has very powerful search options then I would less care for other features which would then become obsolete and less needed, like management of parent-child relations on genres.
Parent-child relations between genres is essentially a tool for management of complexity in the GENRE domain. If one has a large number of genres (i.e. big complexity in the GENRE domain) one could use parent-child relations as a tool to manage this complexity by building a tree that could then be more easily navigated through. In that case one would need feature 1) above.
However if the target vision of the SW has features 4), 6), 8) and 9) above, which essentially means significantly extending its search capabilities, then one would not need parent-child relations between genres at all. In that case the complexity in the GENRE domain would effectively be eliminated with the powerful search engine rather than with building a genre tree. That is to say, the database would be browsed through with the powerful search engine rather than with clicking on the genre tree.
The importance of the target vision cannot be overestimated. Instead of having large number of possibly incompatible features it is better to have less number of features however which are compatible with the future target vision of the SW and which work in harmony one with another. As you see with the parent/child relations in the genre domain - features easily come in but hardly get out of the SW!
b.r. Igor, Croatia
Hi,
Just found your website and downloaded the software. Great job on the design and the pricing is very reasonable.
I have not had time to review your software much but do have a few questions:
1. Is the software open source?
2. I would like to loan books to friends, is there a way to do this? and track what I loan out.
3. is there a way friends could see what I have in my book collection via the web?
Would donations help make these features arrive faster... :)
Thanks
Hi mfisher,
Thanks for your great feedback!
Here are the answers to your questions:
1. no
2. You can create a tag "loaned"
3. You can export your books to html and publish them on your site or blog