Suggesstions on "Widgets 1.0: Packaging and Configuration" document

Hi,

I have read the the following document:

Widgets 1.0: Packaging and Configuration
W3C Candidate Recommendation 14 July 2009
http://dev.w3.org/2006/waf/widgets/

Please find below my suggestions.
Best regards,

Oguz Kupusoglu




Suggestion 1
    Using a separate XML file named “proprietarty.xml” for specifying all the
    proprietary extensions to the "Configuration Document". It will be found
    at the place of the "Configuration Document".

    Rationale
        * Keeping the config.xml file fully standard.
        * Easier maintenance by combining all non-standard stuff separately..
        * Allowing reviewers see the proprietary stuff quickly and cleanly.
        * However, From i18n point of view maintaining one  more file may be
          a burden.



Suggestion 2
    Using a separate XML file named “preferences.xml” for persistently saving
    the user preferences.  It will be found at the place of the "Configuration
    Document".

    Rationale
        * When the related Widget is updated or reset, the Widget Engine can
          easily check or restore the preferences.
        * Allowing reviewers see the preferences quickly and cleanly.
        * However, From i18n point of view maintaining one  more file may be
          a burden.



Suggestion 3
    Assume each widget has a "complaint line": by simply activating it,
    preferably adding some text, the user will inform the widget author and
    widget host, widget gallery or AppStore, that something is wrong with the
    widget. The complaint proceeding depends on the widget host policy. For
    example, if the number of complaints hit a pre-defined threshold the widget
    host may remove the problematic widget or can simply record the number of
    complaints. In fact, this idea is already proposed by Marcos Caceres, see
    "Position on Widget Security" ( http://datadriven.com.au/ ).

    Rationale
        * If a widget is used by technically illiterate people, there should be
          an easy-to-use method for them to inform somebody that something is
          wrong with a widget before they remove the widget. I don't expect
          these people to go to the original place where they downloaded the
          widget to take action. However, if such an easy-to-use built-in
          "complaint line" is available, such people will take action. I am
          working on some widgets to be used on TV's by ordinary people, and
          ease of use with a remote controller is a prime concern for me.



Suggestion 4
    From marketing point of view download rankings are important. For example,
    "Download rankings are key to success since users trawl the most-popular
    lists for games."* Assume each widget has a "rating" option. By activating
    it, the user will send a rating between 0 and 5. Hence, the widget
hosts may
    maintain two separate listings: one is download ranking and the other is
    user rating.

    * Washington Post, Gabriel Madway, Big game publishers muscle in
on iPhone's
      upstarts, 15 July 2009

    Rationale
        * If a widget is used by technically illiterate people, there should be
          an easy-to-use method for them to inform somebody their verdict on the
          widget.
        * At any moment t, the widget users while looking for new widgets have
          more listing to check. This will reduce the pressure on the “download
          ranking” list.

Received on Friday, 17 July 2009 09:14:08 UTC