Greg Brown added a comment - 05/Jan/11 08:25 PM
> ... sheets don't ever slide in from anywhere but the top of a window. As a Mac user, I am familiar with and like that convention.
In which case you would be free to never use the new style to alter the default slide direction!
Respectfully, it almost sounds like you are suggesting this should not be possible in a Pivot class named Sheet, because it is not possible in the Mac component named Sheet which was the inspiration. (Although I am not trying to put words into your mouth)
Would you be happier with a Pivot subclass of Sheet which had a skin that extended TerraSheetSkin with the new style & associated logic to perform the directional animation? That would meet the requirement and is what I have already done in my own code (due the convenience of subclassing library components/skins rather than altering and maintaining a modified source branch)
> Trays are also supported on OS X, but they are not widely used and work slightly differently ...
> The proposed version of Tray would slide in from the sides of the display and would be display-modal.
As mentioned before, I am not aware of anyone having requested the functionality to be display modal, The requirement was just to be able to control the slide animation direction of a Sheet.
> Since many Pivot apps use a single main maximized window, the user experience of a Tray in this case
would be identical to that of your proposed Sheet.
What about the apps where I have multiple Frames and want the possibility for each to have a Frame modal 'Sheet/Tray/whatever' that slides in from a direction other than the top? This suggestion would not meet the previously stated requirement.
> If you simply want content to slide in and out from the side of a window, why not do it within the window itself?
Because 99% of the functionality already exists within Sheet and this seems to be a fine example of the purpose of styles. Perhaps it is not and that is where the confusion is arising?
> You could use a collapsible tab pane for this, or maybe a hypothetical vertical Expander.
Or I could use a Sheet that can have its Slide direction controlled through a new style
Personally, I do not want any extra content painted on the screen as would be the case with a TabPane or Expander. I just want something that looks and behaves like a Sheet to be able to slide in from another direction, and does not require any additional GUI cruft on the parent window.
> Does the content actually need to be modal?
Yes, but only modal to its parent. However I can see the value of changing Sheet to allow a Display as a parent, and also to allow a sheet to be closed with a minumum of effort (as shown in the attached tutorial code)
Greg Brown added a comment - 05/Jan/11 09:03 PM
> ... modal windows like dialogs and sheets require input from the user, and users read from top to bottom.
That user input might be as simple as pressing any key, or clicking the mouse anywhere within the bounds of the modal window or over its parent. It needn't be a complicated form to complete.
Granted users read top to bottom, but that seems moot when the top of the Sheet content will be the last part that is made visible due to the downwards slide animation. Once the animation has completed (regardless of which direction it slides from) the window content would be at its most visible for users to read from top to bottom, or scan images.
> Visually, the eye will be directed towards the top first - the fact that it is horizontally centered serves to emphasize the importance of the interaction.
I feel that the slide animation itself would serve to draw the eye.
This technique is widely used in TV advertising, for example when watching sports on TV in countries where the game is shown without breaking for commercials. An info bar/ticker/banner will slide in from the bottom of the sceen, (compressing the main content slightly, as modality obviously does not apply). I have seen this in TV sports shown in Europe, Asia, Africa, USA & Australia, so it seems widespread. The animation distracts the viewer and draws the eye to the new content, if only for a split second.
> A modal window positioned anywhere else will be confusing, and will not convey to the user that immediate attention is required.
If this is really the case, then doesn't it follow that all modal windows in Pivot should only ever appear bound to the top of its parent? I'm not a fan of inflicting restrictions on the potential uses of Pivot components, so would resist this idea (as I seem to be doing right now!).
If a GUI designer feels strongly about modal window placement, it can be controlled. If they don't, then I don't see why it should be dictated to them. People should be free to create ugly or horrible UI experiences if they so desire!
The Pivot project could conceivably create its own recommendations along the lines of Apple's Human Interface Guidelines, but I they should only ever be guidelines. In any case, it would not be feasible to build in all of the logic to ensure that those guidelines are never broken.
This could start with some content on the Wiki as a series of short 'how to' articles/paragraphs explaining the best or Pivot way to acheive a particular GUI effect.
example 1) Request user input in a modal dialog = Use a Dialog or Sheet, or roll your own with a Window, but place it at such and such a location unless there is a reason not to.
example 2) Add the ability to show & hide TableView columns at runtime = Add a context menu handler to a TableViewHeader, do bounds checking, populate the menu, then add/remove selected columns from the underlying column sequence.
(This is veering off topic, so I will leave it there)
> This means that the Tray concept is probably flawed as well, unless it is implemented as a modeless window (and, now that I think about it, that is exactly how Trays are implemented on OS X). I'd suggest that we consider other alternatives for sliding non-modal content into view.
Again, sliding non-modal content into view was not the original requirement.
Sheet could also be extended to be non-modal and possibly hide itself after a certain period of time. This would provide behaviour that might be referred to as a Notification (as seen in email applications). I can see the value of a dedicated class for that in order to configure the modality and handle the timings, but could also envisage a static helper method on Sheet/Prompt/Tray to achieve the same thing.
Perhaps others have opinions they wish to contribute as I don't think I have anything further to add for now. I have already added this functionality to my code base, so the outcome of this ticket is unlikely to affect me personally.