From: Alex M. <ah...@st...> - 2005-10-27 20:07:03
|
Could you explain briefly what a tableview would look/operate like? i.e. would it look like an outline view, but without the collapsible parts? Mouseless entry is good (one reason I'm not a fan of tabs - they're a pain to move between w/o the mouse). Compactness is also good. One- click to enter something is excellent (just for consistency). Perhaps "easy transition to editing in the pane below the publication table" should be a criterion? -A On Oct 27, 2005, at 2:51 AM, Christiaan Hofman wrote: > Jury, do we have a verdict? > > To remind, we should modify the detail editor. The main reason is > to accommodate the new rating and Boolean fields. there are several > ideas: > 1) an outline view with different categories. > test version at: http://homepage.mac.com/amaxwell/ > 2) a split view with a matrix below the form. > test version at: http://www.weizmann.ac.il/home/hofman/dropbox > 3) a tableview. Similar to the outline view, but with colors/icons > to distinguish categories. > not tried out yet. > > All approaches have their drawbacks. > > Christiaan > > On 15 Oct 2005, at 4:29 PM, Christiaan Hofman wrote: > > >> Let me makee some comments on your comments. >> >> >> On 14 Oct 2005, at 11:46 PM, Michael McCracken wrote: >> >> >> >>> This has been a really interesting thread. I've been keeping up >>> with it slowly, but haven't had time to think much about it until >>> now. I have a couple of comments, but I'm not sure what layout I >>> like best either. I think it's great that we've got some concrete >>> prototypes to play with. >>> >>> First, here's how I see the goals of the editor: >>> - Nice clean look, save some space over current design. >>> (For instance, fields that are always short might be combined >>> on one line and let you see more info without scrolling) >>> - Be flexible: can show+edit arbitrary user fields >>> (So we can't accomplish the above strictly in IB) >>> - Accommodate different controls - ratings, checkboxes, etc... >>> >>> Here's what I thought about the alternatives: >>> >>> Adam's Outline View: >>> I like the cleaner look we get from using an NSTableView/ >>> OutlineView instead of an NSForm. NSForm is so 1999. >>> The outline headers for Required/Optional/Metadata make the >>> vertical space problem worse, unfortunately. >>> I think in a table based editor, we should just use some icons on >>> the same row to show the required/other info. >>> >>> >> One thing I don't like about the table/outline view option is that >> you have to doubleclick to edit. I agree that for this option it >> is probably better to use icons or colored titles rather than an >> outline to distinguish different fields. >> >> >> >>> Combining short fields would be easy enough if we made a custom >>> cell to edit specific ones, like month/year, and just call that >>> row "Date"... It's getting away from a 1:1 bibtex mapping in your >>> head, so that's debatable, but it'd save space. >>> >>> >> >> That would mean some custom checking for special fields like that, >> and whether any one of them is required etc? The logic of the >> setup code will be much more complicated when we do that. >> Otherwise, it might be nice. >> >> >> >>> Getting much fancier with a tableview is not so easy. (Ie, it >>> will always look like a table with rows) >>> It's easier to work with the table view and data source than with >>> NSForm. The code would be nicer. >>> >>> Christiaan's Matrix in a Split View: >>> I like the matrix, but I don't know how I feel about the >>> splitview. Considering precious vertical space, splitviews always >>> seem to be wasting it - maybe the same thing could be done in a >>> matrix side-by-side with the main editing form? A vertical >>> splitview, in other words... >>> >>> >>> >> One reason I thought of the splitview is that it changes the >> editor very little. If people don't use the new types of fields, >> they can just hide them, otherwise they can make it as small as is >> needed. Compared to other options, I don't think the splitview >> wastes so much space, just the divider. I think a vertical >> splitview wastes more space. Note that there usually are not too >> many boolean/rating cells. And it is better to be able to show as >> much as possible of long textfields. >> >> >> >>> As for the matrix, what's your opinion on using a matrix for >>> everything? We could work in the row-sharing (eg, month + year on >>> same row) more easily with a matrix than with an NSForm, and we >>> still get the ability to show arbitrary fields. However, the code >>> doesn't become tons cleaner vs. the NSForm, since NSForm is a >>> subclass of NSMatrix, and thus the code will be pretty similar. >>> >>> >>> >> We then need to subclass NSMatrix so that it basically acts like >> NSForm for the layout. Eg sizing the titles to the largest ones. >> We might also have to make subclasses for the buttons with >> resizable titles like NSFormCell. I don't think it is so much >> easier to get small fields on a single row, except perhaps if >> there is a custom cell which looks like a double NSFormCell. One >> annoying thing with NSMatrix is that all cells must have the same >> size. So you can't really have a column of titles and a column of >> text-or-button cells. I also don't know of a way to have a cell >> span 2 columns or something. I think it can become pretty messy if >> we want to build in all this flexibility into NSMatrix, it is >> certainly not there with the standard implementation. >> >> >> >>> Just some comments, really. I'm not sure which direction to go. >>> When I was mocking up the publication editing UI in BD 2, I went >>> with a pretty static interface, since I reasoned that most of the >>> time you're looking at the info, not editing it, and you often >>> only care about the title, year, and authors when you're looking >>> at it. When you're editing it, you're usually just editing your >>> own metadata like keywords, rating, and comments. >>> >>> I find that I use the table-based editing in the import-from-* >>> sheet to input data now, and almost never just create a new pub >>> and start editing in the bibeditor. In fact, I'd say the only >>> things I really do in BibEditor are add a link to a file, write >>> notes, and look at (but not edit) the other info. Maybe another, >>> condensed view would be useful. Of course, this comes with the >>> caveat that I'm getting good at suggesting more than I code, so >>> take what I say with a grain of salt :) >>> >>> -mike >>> >>> On Oct 14, 2005, at 1:38 PM, Alex Montgomery wrote: >>> >>> >>> >>> >>>> Hmm, interesting. For some reason I feel like the booleans and >>>> ratings should be at the top instead of the bottom. Otherwise >>>> looks nice. When I added a ridiculously long name for a boolean >>>> it resized nicely. >>>> >>>> Bugs: I put in an extra rating-type field and an extra boolean >>>> field; adding the boolean field added both to the form; deleting >>>> either didn't remove them from the form; and the state of the >>>> height of the separator wasn't kept. >>>> >>>> >>>> >> I did not implement all the checks yet. I just added all the >> rating and boolean fields that were defined, without regards to >> whether they were set for the item or not. I am not completely >> sure if we should do that anyway, as everything works even when >> they are not set. I also did not save the position of the >> separator (that would require a new pref, which I don't want to >> introduce just in a test version). >> >> Christiaan >> >> >> >>>> Looks good! >>>> >>>> On Oct 14, 2005, at 7:29 AM, Christiaan Hofman wrote: >>>> >>>> >>>> >>>> >>>> >>>>> I tried out using a split view with a matrix for the rating and >>>>> boolean fields in the editor, as an alternative to the outline >>>>> view. In the test version I also put the cite-key and type on a >>>>> single line to save space. See what you think about this >>>>> layout. You can try it out with the test version on my >>>>> homepage, see >>>>> >>>>> http://www.weizmann.ac.il/home/hofman/dropbox >>>>> >>>>> >>>>> BTW, the large space below the toolbar is used as a status bar. >>>>> You can collapse it using the View > Hide Status Bar menu item. >>>>> Due to the complicated layout of the window it was rather >>>>> difficult to get thee status bar on the bottom of the window, >>>>> which is more standard and nicer. >>>>> >>>>> Christiaan >>>>> >>>>> >>>>> >>>>> <BibDesk-split-editor.jpg> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Bibdesk-users mailing list > Bib...@li... > https://lists.sourceforge.net/lists/listinfo/bibdesk-users > |