Open Questions about BD 2 Design
Questions about the BD2 design that we need to figure out before we start the actual project.
Let's make this a running list, and keep solved problems around at the bottom for historical reference. If a long discussion starts on any of these, refactor it out into a page like 'BD2-question-shouldWeHaveItMakeToast'.
NOTE - This should be a list of design/research questions that are implied by features we want, not a list of feature requests themselves. If we need a page [BD2-feature-requests], we can create it and use it as a source of questions for this page.
- How best to present a useful GUI summary of individual items and support easy 'modeless' editing at the same time?
- How could we display groups that contain multiple types of items?
- Should we use BDSKComplexString as the base storage for strings, like we do in BD1?
- Probably not. Macros are mostly useful for dates and venues. But those are stored as separate objects that contain enough information and should be easy to add. Exporting those using macros could be a setting in the exporter.
- Do we want something like crossrefs?
- How should we support searching for all the various entities?
- Searching within a single type already is partly there using predicates.
- What's the simplest way to support multiple switchable views on the same collection of things, like the map view in the [BibDesk_2.0_Design_Document]?
- Mike's initial implementation in bibdesk_2_test got a little hairy and should be reconsidered.
- Where in groups do we store information for Exporters?
- this one might be simple - the info is really just a dictionary, right?
- Do we need a File entity?
- probably, because there might be some metadata we want to attach to it (when last read, whether it's been printed, etc?), and because that makes it easy to have more than one file attached to an object.
- Should we have file attachments to People and Venues and Institutions, etc, or just to Publications?
- How should we display multiple file attachments? A drag-icon-well won't do it.
- What's the best way to integrate People (and Institutions!) with the Apple AddressBook?
- We don't want to store duplicate data, but we also don't want to store our data in there unless the user requests it.
- Maybe we can have an optional attribute that's the AddressBook UID and then if that exists, we get 'live' data for the attributes it has?
- This begs another question - how much "AddressBook" style data would we really want to display for People?
- I think email, web page, and picture is all we'd want to display, and have a 'show Addressbook entry' button to see the rest... Opinions?
- Where do we put the information dictionaries for Importers?
- Importers for BibTeX may not be run more than once, but the same infrastructure (BDSKImporter) can be used to write an RSS importer that gets run on a schedule and imports new people/pages/etc as you go.
- (A little outside the original BibDesk mandate) If we could find a nice way to collect call-for-papers notifications and store them, should we do that in BibDesk or is that best done via the combination of RSS, email and iCal? (see, it's messy now, right?) If we did it in BibDesk, what's a good way to display them?