Pivot
  1. Pivot
  2. PIVOT-682

Enable slide-in direction specification in the case of Sheet component

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0.1
    • Component/s: wtk-terra
    • Labels:
      None
    • Environment:
      all

      Description

      Dear All,

      As discussed over the forum, it would be a nice feature to be able to define from which side the Sheet component is sliding in. The discussion can be found:

      http://apache-pivot-users.399431.n3.nabble.com/Sheet-sliding-in-from-the-left-right-bottom-Is-there-a-way-tp2032319p2032319.html

      Your work is highly appreciated,

      Regards,

      Zsolt 'MSafiri' Putnoky

      1. 20101221.TerraSheetSkin.slide_direction.patch
        5 kB
        Chris Bartlett
      2. sheets_tutorial.zip
        3 kB
        Chris Bartlett
      3. sheets_tutorial.jpg
        57 kB
        Chris Bartlett

        Activity

        Hide
        Chris Bartlett added a comment -

        Patch & tutorial app to be committed soon unless anyone has any objections

        Show
        Chris Bartlett added a comment - Patch & tutorial app to be committed soon unless anyone has any objections
        Hide
        Greg Brown added a comment -

        >> 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.

        As you noted, the difference is that this technique is commonly used for non-modal content. The advertiser wants the viewer's attention, but it isn't required.

        > 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.

        This is a valid point. Sheets do have characteristics in combination with notifications.

        I was going to say that sheets should always be modal or we'll muddy the definition of their purpose, but that's probably not correct - Dialogs have a modal flag, and sheets could as well. A non-modal sheet could automatically close when the user clicked outside of its bounds (but still over the owner's client area). Also, as you suggested, it could also be configured to close automatically after some time period.

        So while I still question some of the UE principles behind the design, I am OK with adding support for configurable slide directions.

        Show
        Greg Brown added a comment - >> 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. As you noted, the difference is that this technique is commonly used for non-modal content. The advertiser wants the viewer's attention, but it isn't required. > 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. This is a valid point. Sheets do have characteristics in combination with notifications. I was going to say that sheets should always be modal or we'll muddy the definition of their purpose, but that's probably not correct - Dialogs have a modal flag, and sheets could as well. A non-modal sheet could automatically close when the user clicked outside of its bounds (but still over the owner's client area). Also, as you suggested, it could also be configured to close automatically after some time period. So while I still question some of the UE principles behind the design, I am OK with adding support for configurable slide directions.
        Hide
        Chris Bartlett added a comment -

        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.

        Show
        Chris Bartlett added a comment - 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.
        Hide
        Greg Brown added a comment -

        Actually, here is a reason why sheets should slide out from and remain attached to the top of a widow: modal windows like dialogs and sheets require input from the user, and users read from top to bottom. 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. A modal window positioned anywhere else will be confusing, and will not convey to the user that immediate attention is required.

        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.

        G

        Show
        Greg Brown added a comment - Actually, here is a reason why sheets should slide out from and remain attached to the top of a widow: modal windows like dialogs and sheets require input from the user, and users read from top to bottom. 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. A modal window positioned anywhere else will be confusing, and will not convey to the user that immediate attention is required. 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. G
        Hide
        Greg Brown added a comment -

        Mac users would definitely find it odd. I'm not a UE expert, but I assume that the people who came up with the sheet concept are, and 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.

        However, I understand the desire for content that slides in from other directions. That's why I proposed Tray. Trays are also supported on OS X, but they are not widely used and work slightly differently - rather than sliding in from the side of a window, they slide out and remain attached to that side. The proposed version of Tray would slide in from the sides of the display and would be display-modal. 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. Trays could also be useful under other circumstances, even when all windows are not maximized (e.g. the Windows Sidebar).

        If you simply want content to slide in and out from the side of a window, why not do it within the window itself? You could use a collapsible tab pane for this, or maybe a hypothetical vertical Expander. Does the content actually need to be modal?

        Show
        Greg Brown added a comment - Mac users would definitely find it odd. I'm not a UE expert, but I assume that the people who came up with the sheet concept are, and 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. However, I understand the desire for content that slides in from other directions. That's why I proposed Tray. Trays are also supported on OS X, but they are not widely used and work slightly differently - rather than sliding in from the side of a window, they slide out and remain attached to that side. The proposed version of Tray would slide in from the sides of the display and would be display-modal. 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. Trays could also be useful under other circumstances, even when all windows are not maximized (e.g. the Windows Sidebar). If you simply want content to slide in and out from the side of a window, why not do it within the window itself? You could use a collapsible tab pane for this, or maybe a hypothetical vertical Expander. Does the content actually need to be modal?
        Hide
        Chris Bartlett added a comment -

        It sounds like you have thought over the Tray concept. Perhaps you could describe it further, especially how it would differ from, or be similar to a Sheet.

        I understand that many windows will not be maximized but don't really see the relevance here. I'm happy with the functionality that Sheet currently offers, but merely wish to easily modify the direction of the animation. I still intend to use Sheets on top of Dialogs/Frames as I currently do, but do not want to be restricted to them appearing from, and being bound to, the top of the window. If a Sheet slides in from the right and is bound to the right hand side of a non-maximized window, it will still be bound to that location if the window is moved (as in the Windows tutorial you mentioned)

        Being able to open a sheet/tray with the Display as the owner could be useful, but that is a different requirement as are any further skin changes.

        Perhaps only Mac users would find it weird for a Sheet to appear from anywhere other than the title bar? However I doubt that any unnatural feelings would suddenly disappear merely because a Tray, rather than a Sheet, slid in from a different direction.

        I don't have strong feelings either way as to whether this functionality is available via an updated Sheet style or a totally new class, especially if there is good reason to create a new class.

        Show
        Chris Bartlett added a comment - It sounds like you have thought over the Tray concept. Perhaps you could describe it further, especially how it would differ from, or be similar to a Sheet. I understand that many windows will not be maximized but don't really see the relevance here. I'm happy with the functionality that Sheet currently offers, but merely wish to easily modify the direction of the animation. I still intend to use Sheets on top of Dialogs/Frames as I currently do, but do not want to be restricted to them appearing from, and being bound to, the top of the window. If a Sheet slides in from the right and is bound to the right hand side of a non-maximized window, it will still be bound to that location if the window is moved (as in the Windows tutorial you mentioned) Being able to open a sheet/tray with the Display as the owner could be useful, but that is a different requirement as are any further skin changes. Perhaps only Mac users would find it weird for a Sheet to appear from anywhere other than the title bar? However I doubt that any unnatural feelings would suddenly disappear merely because a Tray, rather than a Sheet, slid in from a different direction. I don't have strong feelings either way as to whether this functionality is available via an updated Sheet style or a totally new class, especially if there is good reason to create a new class.
        Hide
        Greg Brown added a comment -

        Duplication isn't necessarily a bad thing. There's lots of duplication already in the platform. From a design standpoint, it can help serve as a sort of insulation for things that initially seem closely related but ultimately prove not to be.

        When a window is maximized, I agree that the user experience for a Sheet or Tray would be indistinguishable. However, not all windows are maximized. Try running the Windows tutorial application and change the sheet slide direction - I think you'll see what I mean. It does not seem natural for a sheet to slide in from any other edge - a sheet is designed to slide down from the title bar of a frame.

        A "tray", on the other hand, could easily slide in from any side of the display. So it seems more natural to make this a new component. Making it a new component also allows us to skin it differently, and I imagine that a tray could easily look different than a sheet.

        Show
        Greg Brown added a comment - Duplication isn't necessarily a bad thing. There's lots of duplication already in the platform. From a design standpoint, it can help serve as a sort of insulation for things that initially seem closely related but ultimately prove not to be. When a window is maximized, I agree that the user experience for a Sheet or Tray would be indistinguishable. However, not all windows are maximized. Try running the Windows tutorial application and change the sheet slide direction - I think you'll see what I mean. It does not seem natural for a sheet to slide in from any other edge - a sheet is designed to slide down from the title bar of a frame. A "tray", on the other hand, could easily slide in from any side of the display. So it seems more natural to make this a new component. Making it a new component also allows us to skin it differently, and I imagine that a tray could easily look different than a sheet.
        Hide
        Chris Bartlett added a comment -

        I am not a Mac user, so can't comment on that side of things, but I can't really see the need for a whole new class (and the duplication that entails) just to be able to change the direction of the slide animation, especially when it can be achieved with the addition of a single style and trivial code changes.

        Sheet behaviour would be unchanged until the new style is changed from default value, meaning that it is not an invasive change.

        Show
        Chris Bartlett added a comment - I am not a Mac user, so can't comment on that side of things, but I can't really see the need for a whole new class (and the duplication that entails) just to be able to change the direction of the slide animation, especially when it can be achieved with the addition of a single style and trivial code changes. Sheet behaviour would be unchanged until the new style is changed from default value, meaning that it is not an invasive change.
        Hide
        Greg Brown added a comment -

        I have not looked at this patch yet, but I wonder if this feature might be best implemented as a new window type. Sheets have a pretty specific purpose (at least, they do on Mac OS X, which is what they are based on). They always appear to slide out from the top of their owner window, and they remain attached to the owner as the user drags it around the screen.

        To me, this seems more like a "tray" that slides out from one side of the display and may not be attached to any particular window (perhaps they are display-modal). What if we create a new Window subclass called Tray and implement this behavior there?

        G

        Show
        Greg Brown added a comment - I have not looked at this patch yet, but I wonder if this feature might be best implemented as a new window type. Sheets have a pretty specific purpose (at least, they do on Mac OS X, which is what they are based on). They always appear to slide out from the top of their owner window, and they remain attached to the owner as the user drags it around the screen. To me, this seems more like a "tray" that slides out from one side of the display and may not be attached to any particular window (perhaps they are display-modal). What if we create a new Window subclass called Tray and implement this behavior there? G
        Hide
        Chris Bartlett added a comment -

        Tutorial script application for Sheets

        Show
        Chris Bartlett added a comment - Tutorial script application for Sheets
        Hide
        Chris Bartlett added a comment -

        Patch allowing users to specify the direction that the sheet slides in from through a new TerraSheetSkin style (and associated enum).

        The behaviour remains much as before, but allows the sheet to slide in from the top, bottom, left or right.
        The sheet will end up aligned on the same side of the parent window as specified by the enum.

        The style was named 'slideSource' to allow a future style of 'slideDestination' to be added later if required.

        Note this does not address the use case where the sheet slides in and stops in the center of the parent window.

        Show
        Chris Bartlett added a comment - Patch allowing users to specify the direction that the sheet slides in from through a new TerraSheetSkin style (and associated enum). The behaviour remains much as before, but allows the sheet to slide in from the top, bottom, left or right. The sheet will end up aligned on the same side of the parent window as specified by the enum. The style was named 'slideSource' to allow a future style of 'slideDestination' to be added later if required. Note this does not address the use case where the sheet slides in and stops in the center of the parent window.

          People

          • Assignee:
            Chris Bartlett
            Reporter:
            Zsolt Putnoky
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development