I suggest to remove alternative view modes for the etext list from pygets.pyw or at least create separate GUI for this functionality.
1) The "All" view mode shows lists of e-Texts, all other modes show summary reports about the list, when usual eText actions (such as "Download") are not applicable.
2) User can get all this information anyway by sorting the table data by different criterias and browsing the list.
3) Currently there is no alternative mode-specific functionality.
4) This will simplify both - GUI and code.
Personally, I think the ability to view only one field of table data at a time (with redundancy removed) is a useful feature. It makes some interactive browsing tasks easier by reducing the amount of data the user has to scan through to see results. I consider the browsing functions to be as important as the download functions in PyGETS, since if the user already knew exactly what they wanted they could simply get the e-texts from the PG website or its mirrors.
One advantage of having a local copy of PG content information is the ability to view the data in ways that are not always possible or easy with fixed-field search forms like that on the PG website. If PyGETS doesn't offer some advantages over existing options, why bother with it? Rather than reducing view flexibility, I'm more inclined to look into ways for possibly increasing it.
Responses to reasons:
1) The fact that downloads are only possible when in the "All" viewing mode is made apparent by enabling and disabling the download buttons as appropriate. In all other respects the browsing interface is the same whether the view mode is "All" or one of the individual field types. I think this consistency is a good thing to preserve, which is why I'm not in favor of creating another GUI component for the individual viewing modes.
2) The user experience is not the same when all field information is included in results. For example, consider looking for a work by an author whose name was only vaguely remembered as starting with the letter K. By viewing only the author names filtered with the regular expression "^K" in the author filter field, the user can quickly look through the results to see if any name looked familiar. The filter conditions can then subsequently be modified to limit the list of candidate authors and the view mode switched to "All" to produce the list of downloadable e-texts. Accomplishing this with only the "All" view mode is possible, but is more cumbersome for the user.
3) As stated above, the act of browsing is itself a primary function of the application. The single-field view modes are intended to make certain browsing patterns easier for the user.
4) Since I do not think the features should be entirely removed, the only alternative would be to create a separate set of GUI components to perform nearly identical functions to what is already included. This would not simplify either the GUI or code implementations.
The problem is not that application has different views on the same information. My main objection is that we show different information in the same GUI element. I consider eText list to be very different from a summary report. Look at any other application - different view modes show the same items.
What if we provide functionality to load data in a spreadsheet (Excel, OpenOffice, KSpread, Gnumeric)? This gives us a few advantages:
1) satisfies your requirements
2) provides users with more powerful data analysis tool we can ever hope to create
3) the spreadsheet application is familiar to the users
4) eliminates need to implement this rather complex functionality and GUI ourselves
1) the functionality is not obvious. We can name this action "Analyse and Search eText List" to make it more obvious.
2) Requires a spreadsheet application. In this case we can notify user that he can get nice Free office suite, including a spreadsheet application from OpenOffice.org (now this is an advantage ;-)
I'm currently working on a Windows machine and can test the application with Excel and OpenOffice.org.
I meant "Cons" instead of "Pros" in the previous post.
Actually, I can think of one very popular application class which uses the same display component to show many different kinds of data -- browsers. The spreadsheet applications you mention also use the same visual area to display different kinds of data, and not every cell holds the same data types or allows the same operations on its contents.
With PyGETS I think the primary function of the display window is viewing data, either in whole or in part. The ability to download by selecting entries from the view window is a capability that is supported only in one view mode, which is not inconsistent with the model used in other applications which tailor functionality to what is reasonable for the given mode.
Creating a separate viewing UI component just to get summary information would only make the application more complex and require the user to go through more steps to get similar results. I don't see how this is a win for anyone.
BTW, your idea of exporting data to external applications is nearly trivial to implement. The application already outputs a CSV file which contains a subset of the data for use by PyGERS. A complete CSV dump, which should be readable by most spreadsheet and database applications, would be easy to add. It's also easy for custom applications to read the XML data file directly using a number of available XML parsers.
PyGETS was not intended to be a powerful analysis tool, but simply a way for users to browse through the growing selection of e-texts offered by Project Gutenberg. Summary views are one way to make the browsing experience more manageable, considering that the number of entries is now in the thousands, while preserving a consistent UI throughout the process.
P.S. Thank you for your patch contributions. I'm working through them as fast as I can. :-)
> Actually, I can think of one very popular application
> class which uses the same display component to
> show many different kinds of data -- browsers.
> The spreadsheet applications you mention also use
> the same visual area to display different kinds of
> data, and not every cell holds the same data types
> or allows the same operations on its contents.
I'd say that both - browsers and spreadsheet work on more abstract and general level. Spreadsheet works just with tabular data and operations on data depend mostly on data type.
Browsers work on "request - request results" level where request can be of a many types.
PyGE on other hand works on leve of eTexts and we just jump to different subject without telling user anything.
Anyway, I don't mind to have different view modes. We can change this later if we want to.
> P.S. Thank you for your patch contributions.
> I'm working through them as fast as I can. :-)
You are welcome.
Don't worry, I don't code so much all the time - only when have some time and ideas.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.