On 3 Nov 2014, at 11:13 am, Luther Baker <lutherba...@gmail.com> wrote:
> You start the app and if you select a milestone I show a "milestones detail > editor view" in the right "details" area. Also, after selecting that > milestone, a hierarchical view of milestone tasks shows up in the middle > view. Now you select one of the tasks the details area changes to show a task > editor for that specific task. All good so far. Why not make the milestone tasks children of a milestone item in the same outline view? Then you remove the ambiguity of which item is selected - there's only one, whether it's a milestone, a task or a subtask. The detail view should display whatever's appropriate to the 'level' of the item selected. Depending on the complexity of your details though, these could even be inline as items in the outline view itself. View-based outline view rows make that much easier than it used to be, and often more versatlie, since if the user decides to open more than one at a time, they can, and just edit freely. > Is FR a rabbit hole ... bcs naively, it certainly seems to be what I'm > looking for. If your detail view changes according to FR status, I think it'll become a rabbit hole, because of the case of neither outline view having focus. What does the detail view display then? Nothing? If so, tabbing into a detail view field will remove all of the views from the detail view, including the field you just tabbed into. Derp. > I was trying to keep everything in one window. Are people not contextually > repurposing areas like this? Master-detail designs are fine, in many cases. I'm not suggesting you don't do that, just avoid the potential ambiguity of having two master views. > In my mind, I was thinking "It's always an editor of whatever is currently in > focus.". It can't be, because parts of the editor itself will sometimes (often) have the focus. It should be "an editor of whatever is selected". But to make that work you don't want the selection to be ambiguous. So extend the hierarchy so that milestones are containers for task groups, and releases are containers for milestones. Also, if you allow *multiple* selections in the table, consider how you'd make that work. For example, if all tasks share a detail interface, and you select more than one task, would it be useful to allow the detail editor to allow values for those several tasks to be edited simultaneously? All values or only some? How do you display values that differ among the tasks? The question can be avoided by only allowing one selection at a time, but this could limit the user's abilities in ways that cause other issues. Suppose they need to change some value of a whole lot of tasks to some common value - if they have to do this one item at a time they'll be cursing you. (n.b. bindings has solutions for many of these questions). > Is Xcode worth considering here? Tap a class file and you get details about > that class in the right pane. Open a XIB ... Tap something in the XIB and the > details pane changes to reflect the XIB selection, not the file anymore. Same > goes for core data modeling while creating entities. > > Does that not demonstrate a potentially fine way to build user facing > software? The selection in Xcode's source list chooses an appropriate editor for the selection. One of those editors - IB - has its own outline view for its object hierarchy. But that second outline view is really the "detail", not a master picker for further detail - the rest of the view shows a different representation of the same information, laid out spatially rather than hierarchically. That's why the two representations' selections stay in synch - they're two views of the same thing. (i.e. with IB showing you have master->detail+detail, not master->master->detail). --Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
