Again - thanks for the extended notes here. I really appreciate the extra context I get form this group.
Thanks, -Luther On Sun, Nov 2, 2014 at 6:56 PM, Graham Cox <graham....@bigpond.com> wrote: > > 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
