Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.9.2
    • Component/s: None
    • Labels:

      Description

      One of the common problems with sites that consist of multiple widgets is that they just luck messy. Each widget designer will create their own look and feel and chaos ensues.

      Wookie should provide a facility to skin widgets in order to keep them consistent on a single site. This requires:

      • design guidelines
      • common CSS
      • CSS override ability

      The design guidelines defines the recommended approach for designing a widget. It will provide a template for common widget layouts and CSS identifiers for common elements.

      1. footer.txt
        0.3 kB
        Bernhard Hoisl

        Activity

        Hide
        Scott Wilson added a comment -

        Sounds like a good idea.

        Show
        Scott Wilson added a comment - Sounds like a good idea.
        Hide
        Scott Wilson added a comment -

        Definitely worth doing - I'm putting this against 0.8.2

        Show
        Scott Wilson added a comment - Definitely worth doing - I'm putting this against 0.8.2
        Hide
        Ross Gardler added a comment -

        A plan for implementation (comments welcome)

        <div id="wookie-widget">
        <div id="wookie-toolbar">This is where the toobar will be</div>
        <div id="wookie-content">This is where the content will be</div>
        <div id="wookie-footer">This is where the footer will be</div>
        </div>

        We also need to provide a default CSS for rendering this as, for example:

        -----------------------

        TOOLBAR

        -----------------------

         
        CONTENT
         

        -----------------------

        FOOTER

        -----------------------

        This will need to be documented and all widgets should be changed to conform to
        this format.

        We would need to document this on the Wookie website and also document how to
        extend this.

        Once all this is in place I would like to start extending it to provide docuemnted
        CSS identifiers to be used in common cases, for example, we may want to define
        "wookie-navigation" as being used for a common navigation menu. We can then provide
        various CSS alternatives for rending this as a vertical navigation menu or drop down
        menu, or whatever.

        Show
        Ross Gardler added a comment - A plan for implementation (comments welcome) <div id="wookie-widget"> <div id="wookie-toolbar">This is where the toobar will be</div> <div id="wookie-content">This is where the content will be</div> <div id="wookie-footer">This is where the footer will be</div> </div> We also need to provide a default CSS for rendering this as, for example: ----------------------- TOOLBAR -----------------------   CONTENT   ----------------------- FOOTER ----------------------- This will need to be documented and all widgets should be changed to conform to this format. We would need to document this on the Wookie website and also document how to extend this. Once all this is in place I would like to start extending it to provide docuemnted CSS identifiers to be used in common cases, for example, we may want to define "wookie-navigation" as being used for a common navigation menu. We can then provide various CSS alternatives for rending this as a vertical navigation menu or drop down menu, or whatever.
        Hide
        Bernhard Hoisl added a comment - - edited

        When using the template for issue Wookie-133 I encountered that when inserting content as, for example
        <h1>Header</h1>
        in <div> 'wookie-content' the footer disappears. There seems to be incorrect behaviour when using 'min-height' attributes. It would be nice if the footer appears at the bottom of the widget, but I would rather have it at the end of the content of a widget if this means it will certainly get displayed. That is why I just commented out the min-height CSS attribute.

        Maybe this needs some more testing with other browsers/OS and a generic solution can be found.

        I used Google Chrome 7.0.517.41 beta and Firefox 3.6.10 with 64-bit Ubuntu (Kernel 2.6.32-25-generic) and both browsers showed the same behaviour.

        -Bernhard

        Show
        Bernhard Hoisl added a comment - - edited When using the template for issue Wookie-133 I encountered that when inserting content as, for example <h1>Header</h1> in <div> 'wookie-content' the footer disappears. There seems to be incorrect behaviour when using 'min-height' attributes. It would be nice if the footer appears at the bottom of the widget, but I would rather have it at the end of the content of a widget if this means it will certainly get displayed. That is why I just commented out the min-height CSS attribute. Maybe this needs some more testing with other browsers/OS and a generic solution can be found. I used Google Chrome 7.0.517.41 beta and Firefox 3.6.10 with 64-bit Ubuntu (Kernel 2.6.32-25-generic) and both browsers showed the same behaviour. -Bernhard
        Hide
        Scott Wilson added a comment -

        Having a footer always appear at the bottom of the viewport is a problem that is very difficult to resolve in CSS alone - I've usually resorted to using JS to reset the position - see WOOKIE-153 for an example of this sort of layout.

        Show
        Scott Wilson added a comment - Having a footer always appear at the bottom of the viewport is a problem that is very difficult to resolve in CSS alone - I've usually resorted to using JS to reset the position - see WOOKIE-153 for an example of this sort of layout.
        Hide
        Ross Gardler added a comment -

        I'm not seeing this problem in Firefox, IE or Chrome.

        I don't like the idea of a floating footer, and wouldn't it just float of the page if the texst was too long? Might well do so with the CSS i've put in there anyway.

        I really fon't like the idea of doing layout in Javascript that is just wrong in my opinion. Way to hard to manage (change the height of the footer and you have to edit the javascript). Sure, we could calculate the height of the footer in the javascript routine, but that sounds like a hack. Plenty of sites do this without javascript so I don't see why we can't. All we need is someone with the time to explore it and do the CSS.

        I'm leaving as is for now, but this issue remains open for many reasons, not jus the footer problem.

        Show
        Ross Gardler added a comment - I'm not seeing this problem in Firefox, IE or Chrome. I don't like the idea of a floating footer, and wouldn't it just float of the page if the texst was too long? Might well do so with the CSS i've put in there anyway. I really fon't like the idea of doing layout in Javascript that is just wrong in my opinion. Way to hard to manage (change the height of the footer and you have to edit the javascript). Sure, we could calculate the height of the footer in the javascript routine, but that sounds like a hack. Plenty of sites do this without javascript so I don't see why we can't. All we need is someone with the time to explore it and do the CSS. I'm leaving as is for now, but this issue remains open for many reasons, not jus the footer problem.
        Hide
        Ross Gardler added a comment -

        Another approach to this, which is implemented in the JQueryMobile template is to use, well, JQueryMobile. Unfortunately, at the time of writing there arw now two different "standards" for our widget UI. We want to unify the various templates provided on a single stnadard (i.e. using the same class names etc.).

        Show
        Ross Gardler added a comment - Another approach to this, which is implemented in the JQueryMobile template is to use, well, JQueryMobile. Unfortunately, at the time of writing there arw now two different "standards" for our widget UI. We want to unify the various templates provided on a single stnadard (i.e. using the same class names etc.).
        Hide
        Scott Wilson added a comment -

        I really like the idea of using JQuery Mobile - most of our widgets behave very much like mobile applications anyway and so the style fits.

        Show
        Scott Wilson added a comment - I really like the idea of using JQuery Mobile - most of our widgets behave very much like mobile applications anyway and so the style fits.
        Hide
        Scott Wilson added a comment -

        OK, a couple of problems with JQuery Mobile, but I think fixable.

        Basically, JQM assumes the widget is a top-level window, not an iframe, and this means there are a few bugs. Firefox and Chrome seem OK, but Safari has a problem with the "back" button not working - this can be fixed by changing "window.history.back()" to "self.history.back()" in JQM - I've posted this on the JQM tracker so I'll see if this gets included. If not, we have to use a fork of JQM

        I've also seem an intermittent glitch with the fixed-position headers, and there are a slew of issue reports on those. It may be worth not bothering with fixed headers as the default.

        Show
        Scott Wilson added a comment - OK, a couple of problems with JQuery Mobile, but I think fixable. Basically, JQM assumes the widget is a top-level window, not an iframe, and this means there are a few bugs. Firefox and Chrome seem OK, but Safari has a problem with the "back" button not working - this can be fixed by changing "window.history.back()" to "self.history.back()" in JQM - I've posted this on the JQM tracker so I'll see if this gets included. If not, we have to use a fork of JQM I've also seem an intermittent glitch with the fixed-position headers, and there are a slew of issue reports on those. It may be worth not bothering with fixed headers as the default.
        Hide
        Scott Wilson added a comment -

        JQueryMobile is now loadable as a feature and seems to have fixed the issues we had problems with previously. I think it makes sense as a default "skin" for widgets. Unless there are any specific actions we should take for widget skinning, lets close this.

        Show
        Scott Wilson added a comment - JQueryMobile is now loadable as a feature and seems to have fixed the issues we had problems with previously. I think it makes sense as a default "skin" for widgets. Unless there are any specific actions we should take for widget skinning, lets close this.
        Hide
        Paul Sharples added a comment -

        I'd like to ask others confirm if the JQueryMobile template is the default template to use? As Ross said earlier, we have (at least) 2 different standards.

        In the "wookie/widgets/widget-template" folder there is...

        basic - I presume based on Ross' original layout for the skin
        jquery-mobile - what it says on the tin!
        setting - similar to basic in its layout
        wave - similar to basic in its layout
        s5 - presentation type widget - different to others

        These are documented on the wookie project site and the seed-widget ant task asks the user which one these templates to base it from. Do we need to do anything else here? (i.e if jquerymobile is now the default, then some of the templates using the 'basic' layout could be updated)

        Show
        Paul Sharples added a comment - I'd like to ask others confirm if the JQueryMobile template is the default template to use? As Ross said earlier, we have (at least) 2 different standards. In the "wookie/widgets/widget-template" folder there is... basic - I presume based on Ross' original layout for the skin jquery-mobile - what it says on the tin! setting - similar to basic in its layout wave - similar to basic in its layout s5 - presentation type widget - different to others These are documented on the wookie project site and the seed-widget ant task asks the user which one these templates to base it from. Do we need to do anything else here? (i.e if jquerymobile is now the default, then some of the templates using the 'basic' layout could be updated)
        Hide
        Ross Gardler added a comment -

        The templates you refer to are not intended to resolve this issue. Each of these templates is designed to provide basic functionality and demonstrate some of the key features needed in a W3C widget. See See http://markmail.org/thread/275767sda32prucn for the original proposal. So:

        basic - a very basic widget demonstrating the recommended structure (which is as defined in this issue)
        jquery-mobile - a suggestion on a standard approach for jQueryMobile widgets (they provide the skin/theme)
        setting - demonstrates the reading and setting of properties in a very flexible way (i.e. no need to write loads of code)
        wave - Demonstration of how to use wave features
        s5 - demonstration of how to present slides in a widget

        With respect to this issue I recently proposed a solution that provides a templating system to replace the existing one. This new system will address both the functionality templates we already have and the skinning that this issue addresses. See http://markmail.org/thread/scgeyrobljqk7zhz

        The code for this new system will be brought into the Wookie scratchpad very soon. It is pre-alpha functional right now and under rapid development. If you want to look at it before I get the time to drop it here you can fnid it in apache-extras at http://code.google.com/a/apache-extras.org/p/rave-in-context/source/browse/ (it's already Apache licensed and I am committed to bringing it here, so you are safe to experiment).

        With respect to your specific question "is JQueryMobile the default template" I would say no. JQueryMobile is great, however it is only really appropriate for mobile devices. It works on desktop browsers (for the most part), but some of the interaction mechanisms (like swipe) are alien to desktop. That being said it is possible to build widgets using only the features of JQueryMobile that make sense on the desktop as well as the browser.

        The new templating system will (theoretically) be able to replace the UI framework with one more appropriate for your target devices. That is, you would have two sets of templates one for desktop and one for mobile. When you run the "ant generate-templates" command it would build two separate widgets for you.

        NOTE: I say "theoretically" because I have no plans to actually implement that at this point. However, it is a direction I expect to go in the future and would welcome input in that direction.

        Show
        Ross Gardler added a comment - The templates you refer to are not intended to resolve this issue. Each of these templates is designed to provide basic functionality and demonstrate some of the key features needed in a W3C widget. See See http://markmail.org/thread/275767sda32prucn for the original proposal. So: basic - a very basic widget demonstrating the recommended structure (which is as defined in this issue) jquery-mobile - a suggestion on a standard approach for jQueryMobile widgets (they provide the skin/theme) setting - demonstrates the reading and setting of properties in a very flexible way (i.e. no need to write loads of code) wave - Demonstration of how to use wave features s5 - demonstration of how to present slides in a widget With respect to this issue I recently proposed a solution that provides a templating system to replace the existing one. This new system will address both the functionality templates we already have and the skinning that this issue addresses. See http://markmail.org/thread/scgeyrobljqk7zhz The code for this new system will be brought into the Wookie scratchpad very soon. It is pre-alpha functional right now and under rapid development. If you want to look at it before I get the time to drop it here you can fnid it in apache-extras at http://code.google.com/a/apache-extras.org/p/rave-in-context/source/browse/ (it's already Apache licensed and I am committed to bringing it here, so you are safe to experiment). With respect to your specific question "is JQueryMobile the default template" I would say no. JQueryMobile is great, however it is only really appropriate for mobile devices. It works on desktop browsers (for the most part), but some of the interaction mechanisms (like swipe) are alien to desktop. That being said it is possible to build widgets using only the features of JQueryMobile that make sense on the desktop as well as the browser. The new templating system will (theoretically) be able to replace the UI framework with one more appropriate for your target devices. That is, you would have two sets of templates one for desktop and one for mobile. When you run the "ant generate-templates" command it would build two separate widgets for you. NOTE: I say "theoretically" because I have no plans to actually implement that at this point. However, it is a direction I expect to go in the future and would welcome input in that direction.
        Hide
        Scott Wilson added a comment -

        OK, so it sounds like this issues isn't resolved yet but then neither is it a block on the 0.9.1 release.

        Show
        Scott Wilson added a comment - OK, so it sounds like this issues isn't resolved yet but then neither is it a block on the 0.9.1 release.
        Hide
        Paul Sharples added a comment -

        agreed

        Show
        Paul Sharples added a comment - agreed
        Hide
        Scott Wilson added a comment -

        Depends on bringing in new templating system

        Show
        Scott Wilson added a comment - Depends on bringing in new templating system
        Hide
        Scott Wilson added a comment -

        Rescheduling for 0.9.2.

        Show
        Scott Wilson added a comment - Rescheduling for 0.9.2.
        Hide
        Ross Gardler added a comment -

        The new widget templates provide skinable widgets through the provision of JQueryMobile themes and consistent widget templates. See /widgets/templates

        Show
        Ross Gardler added a comment - The new widget templates provide skinable widgets through the provision of JQueryMobile themes and consistent widget templates. See /widgets/templates
        Hide
        Paul Sharples added a comment -

        Verified

        Show
        Paul Sharples added a comment - Verified

          People

          • Assignee:
            Unassigned
            Reporter:
            Ross Gardler
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development