On Dec 14, 2006, at 6:38 AM, M. Uli Kusterer wrote: just curious: What's the rationale behind having both a "Groups and Files" view and a "Detail View"? I personally would have designed these two lists to be unified in one. What advantages do I have with the current design, and how do the people here take advantage of that? Can anyone from the Xcode team chime in with the thoughts behind this design?
Sure, it's pretty simple.
People want their project trees to be vertical outline views, which is what they're used to in CodeWarrior, Visual Studio, Eclipse, etc. These can be very tall, but people generally use outline processing and type-select to navigate. They value the spatial organization of the vertical list, and a vertical stack of (shortish) names and icons is the most compact representation.
On the other hand, they also want to see expanded tabular information. For each file, the build status, the SCM status, the file size, target membership, etc. If you start adding all these columns to the vertical list, it starts getting square rather than tall, and eats up too much horizontal space you want to dedicate to editing.
This is especially true for the non-project-file items in the Groups and Files tree, which have much longer detail information:
- Project Symbols, with kind and location - Errors and Warnings, with error/warning text - Find Results, with context where found - Bookmarks, with location, context, and comments
The master/detail pattern where the master is a narrow vertical list and the detail is a short, broad set of columns gives us a way to represent both kinds of information simultaneously, while retaining a big space for your source editing.
Now we somewhat arbitrarily allocate different behaviors to the Groups and Files versus Detail views. You can sort by column in Detail view, for example, but not in Groups and Files, because there we retain Finder-like user-defined grouping and ordering. You have a collapsable outline view in the Groups and Files but generally not in the Detail view.
In truth we could have one common view that did everything, and you could just have two, make one tall and the other wide, and configure it the way you want, but that gets conceptually muddy and leads to confusion. We think that the clear roles for the master v. detail help people use them in the ways they work well.
Chris |