Share via


The Selection and Visibility Pane (Part 1 - Design)

The Selection and Visibility Pane (called "Selection Pane" for short) is a new feature in Office 2007. It is an OfficeArt shared feature and appears in PowerPoint and Excel. Its main purpose is to help you manage complex drawings and especially complex animations. Unlike a posting to the PowerPoint/OfficeArt blog which is run by program management, I'm going to give you some of the problems we had to solve and our design decisions first before showing the screenshots and giving you pointers for using the feature. There were a lot of discussion here by a number of passionate people in various disciplines. My recollection of some points is a little fuzzy, so bear that in mind.

The Selection Pane exposes two properties of shapes to the end user via the UI for the first time: The shape’s Name and the shape’s Visibility.

The name and visibility properties existed in previous versions of the Office product. In previous versions, these properties were visible to the Office development tools, and developers used these properties as they saw fit without it affecting the user in any way. With the introduction of UI to give users access to these properties, we needed to make a few additional changes. There were many difficult tradeoffs which needed to be made between behavior of legacy functionality, potential privacy concerns, international/multi-language documents, and programmatic access. I'll discuss the tradeoffs briefly and how the final design of the pane and supporting features accommodate the issues. It is my personal belief that the resulting design gives the most power to the users while still protecting privacy and making sure that developers can still work with these features with a minimal amount of breaking scripts and plug-ins.

Shape Name:
The name property in previous versions of Office consisted of a "Friendly Name" which was generated in the UI language and shown to the user in places like the "Custom Animation Pane" and in the "Select Multiple Objects Dialog". Each shape also had an "Object Model Name" which if not set defaulted to the "Friendly Name" except that it was generated in US English instead of the UI language. Some scripts/code may depend on these names, but these names have no explicit guarantees, and we changed the way that we generate them in the Office 2007 release.

After many discussions about uniqueness and guaranteeing uniqueness, and using one name vs. two, it was decided that making this work the way we did before would cause the user needless headaches. In Office 2007, we reduced this down to only one name property. So Office developers take note: If you wrote code looking for "Rectangle 1", you really meant to be looking for the shape whose ID is 1 and whose geometry is a rectangle, because your users might not be using English as their language or they might have changed the name in the Selection Pane. It is not robust to rely on a user-adjustable setting to stay the same. It is also not robust to rely on a shape remaining in the z-order which it was positioned in. If you look at the list of shapes in a drawing, they are listed in “drawing order” (reverse z-order), which is not guaranteed to be the same as their ID order (because you can reorder the shapes with Send Backward/Bring Forward). Shape IDs are unique within their containing drawing.

Shape Visibility:
In Office 2003, the Visibility property of a shape was only available via the Object Model. Now that the hidden properties are accessible to the end user without breaking out a development environment, we had to make some tough choices. Several designs presented themselves, and there was a great amount of concern that people would use the Selection Pane to hide sensitive data within documents. There were many alternative ideas floated to combat these concerns with several variations on each, and each had tradeoffs. Here were some of the ideas (to give you a sense of the variety of ways that we looked at solving the potential problems):

  1. An extreme option which was discussed early is to delete all hidden shapes when opening or maybe when saving. This approach has obvious drawbacks because it deletes user data without asking and would break older Office scripts and plug-ins as well as some collaboration features if you opened a binary with hidden shapes and resaved it in Office 2007. It also would not be consistent with auto-save. Something like a power failure would cause you to lose hidden shapes that should be saved.
  2. A less extreme option was to have a temporary/view-dependent visibility property. The theory behind this idea was that users hide shapes because they are working on a complex drawing and when the user is finished and enters slide show, the users still want to see and animate those shapes. The original Visibility property (it is still needed for certain legacy functionality such as "Send for Review") here would remain truly hidden, and those shapes would not be shown in the Selection Pane. A downside to an approach like this is that you now have two invisibility properties and they do two different things (just like having two names that do different things added too much complexity).
  3. Another option was to continue to use the Visibility property as-is, but to only hide invisible shapes when the Selection Pane was up. Several variants of this idea were discussed, including showing the invisible shapes as ghost shapes with some adjustable amount of transparency slider in the Selection Pane. This is a nice idea, but just like option 2 above, you can get into a state where you have problems working between versions of the product. One version shows the hidden shapes in slide show, and the other one doesn't.
  4. There were many other potential designs each with their own set of tradeoffs.

The final design was to stick with the previous visibility property behavior (which makes the behavior consistent between versions of the product) and make an additional tool available to work with and remove hidden shapes. The Selection and Visibility Pane itself is a tool to view hidden shapes and change their visibility state, so by having this feature in the product, we are providing a way to "see" and work with these hidden shapes. In the Selection Pane, there are buttons to show or hide all shapes in the current drawing (PowerPoint Slide/Excel Worksheet). The tool to remove hidden shapes is part of the Document Inspector which can be found in what I have to call the "File Menu".

So that's a little bit on the design tradeoffs of these two properties. Next time, we'll walk through the UI, go over keyboard shortcuts, give you some screen shots, and talk about how it works with the Custom Animation Pane in PowerPoint to make it easy to tell a story or how it works by itself in PowerPoint or Excel to help you work with a lot of overlapping shapes.

This posting is provided "AS-IS" with no warranties, and confers no rights.

Comments

  • Anonymous
    August 30, 2006
    Hi Mike,

    Thank you for adding some 'how we got here' perspective of the design process.  It's appreciated.

    You mention that the Selection and Visibility Pane are part of the Shared codebase for OfficeArt in Office 2007, yet Word is not included.  

    Can you elaborate a bit, along the lines of the decision making process you used in this blog,  on why Word didn't also gain the pane and how that will effect both users and developers looking for a common presentation elements (look, feel, repurposed content) in all three apps?

    With Word not having the selection pane, are shape properties treated differently and if I send a PPT presentation to Word from Powerpoint does Word retain any editing capability of shapes? (i.e. is Word 2007, without the full OfficeArt shared feature set basically considered a 'legacy' app when trying to share OfficeArt 2007 shapes/content between PPT, Excel and Word?)


    Thank you,

    Fred

  • Anonymous
    August 31, 2006
    Fred wrote:
    "You mention that the Selection and Visibility Pane are part of the Shared codebase for OfficeArt in Office 2007, yet Word is not included.  

    Can you elaborate a bit, along the lines of the decision making process you used in this blog,  on why Word didn't also gain the pane and how that will effect both users and developers looking for a common presentation elements (look, feel, repurposed content) in all three apps?"

    Howard Cooperstein talks about the ways which Word integrated with OfficeArt 2.0 in this podcast: http://www.theiwcenter.com/2006/08/office_art_20_prodcast_howard.html. He touches on these points between time frames 17:05 and 19:30.

    As for your question about if you send handouts from PowerPoint to Word, the answer is that Word embeds PowerPoint slides in each page, so you can edit the embedded shapes via PowerPoint within Word's OLE container.

  • Anonymous
    April 19, 2009
    Hi, The Selection and Visibility screen in Powerpoint is a good addition BUT the syntax should be documented somwhere e.g. 'Textbox 1' is REALLY risky..... Why not Textbox1, hence Textbox01 or Textbox0001 are also acceptable. Brian  

  • Anonymous
    April 22, 2010
    Hi, Great Feature, But can a developer access it? Why would a developer need to access it? Well, to traverse over the selection hierarchy... There is no way to programmatically identify subgroups... The groupitems property gives the basic shapes even if they are actually grouped in a sub group

  • Anonymous
    April 30, 2010
    I thought it would be nice to comment on these questions: Why would a developer need to access it? That indeed is a good question. However, the subgroup heirarchy is more there for informational purposes than it is for manipulation purposes, and you can examine it in the OOXML when you save the file if you really want more information about the subgroups. To answer your question, though, there is no way to traverse over the group heirarchy/middle group objects within a selection because selection in OfficeArt doesn't work that way, and the reason is that there are more properties on a group than just children. For example, 3D transforms. If you make a Group 3D and apply a transform to that group like 3D rotation, then the positions of the child objects with respect to the group are now 3D locations. Ungrouping, adding objects, and "grouping" (i.e. not "regrouping") loses the 3D formatting properties. 3D is just one specific example. Animation properties are another example that apply uniquely to the top-level objects. To answer Brian Keedwell's question about why the syntax is undocumented, just run PowerPoint in another language (Japanese for example), and notice that these names are no longer in English or even in ASCII. Your users can edit these names - they are document data. Don't rely on your users not editing the names. Use the shape IDs instead. And even those can change - rename a pptx file to .pptx.zip and look at the slides in XML. If you want to know what kind of object you have, you can always look at the shape's type property via the OM. Happy coding! -Mike