W3C home > Mailing lists > Public > public-webplatform@w3.org > December 2013

RE: Page Status Indicators

From: David Kirstein <frozenice@frozenice.de>
Date: Wed, 4 Dec 2013 23:59:41 +0100
To: "'Julee Burdekin'" <jburdeki@adobe.com>, "'Doug Schepers'" <schepers@w3.org>, "'WebPlatform Community'" <public-webplatform@w3.org>
Message-ID: <003701cef144$84a32e80$8de98b80$@frozenice.de>


Thanks Eliezer for taking up the challenge that is SMW. An addition the Template Corps would be nice indeed. :)


Maybe we can get around the script, I tried some constructs with #if etc. at http://docs.webplatform.org/wiki/User:Frozenice/PropTest

feel free to play around with it (don’t get scared by the code):


{{#set:High-level issue=Missing Relevant Sections}}

{{#set:High-level issue=Unreviewed Import}}

current issues: {{#show:{{FULLPAGENAME}}|?High-level issue}}

{{#arraymap:{{#show:{{FULLPAGENAME}}|?High-level issue}}|,|x|{{#ifeq:x|Unreviewed Import|{{#set:High-level issue=Needs Review}}|}}|}}


This prints "current issues: Unreviewed Import, Missing Relevant Sections, Needs Review"


So we could check if whatever property contains a particular value (it can easily expanded to check multiple things) and then set another property to a specific value. If there is a checkbox in the Semantic Form, it should get checked (set to true) and our new property value should stick, even if the property we checked changes. That’s the theory so far, it needs to be tested if it actually propagates automatically when only modifying a template etc. (and should probably done at the bottom of the page, but I’m not quite sure in which steps (S)MW parses the page / templates and sets the properties). My simple tests on my test page were partly inconclusive (I sometimes had to purge the page, but I think it will work better with templates / it should automatically get purged and refreshed at some point (SMW properties can take some time to propagate)).


Well, maybe a script is put together faster than this, but I always enjoy fiddling around with SMW. ;)


If Eliezer (or anybody) has questions regarding (S)MW: grab me on IRC or send me a mail if I’m not there! Happy to help, our template system can be hard to understand.







-----Original Message-----
From: Julee Burdekin [mailto:jburdeki@adobe.com] 
Sent: Mittwoch, 4. Dezember 2013 22:42
To: Doug Schepers; WebPlatform Community
Subject: Re: Page Status Indicators


This is great news! Thanks much, Eliezer & Doug!!


As far as losing all of the existing flags, that’s a big deal, no? Is

there no way to flag flagged pages? — Ugh. Just the sound of that question

intimates a difficult solution, but let me propose:


We already have a “Block of editorial notes” field where we can store some

values on the page. Let’s do a script and retain flagging in this way:


* Get the values of current flags on the page.

* Change old values to new values.[1]

* Prepend new values to “Block of editorial notes” field with some unique



Then, we can change the template and work in reverse:


* Search page for new flags in “Block of editorial notes” field.

* Set new flags accordingly.


Too complicated?





 <https://docs.google.com/spreadsheet/ccc?key=0AnXre3v9CjJXdDBUYk9qMlFuODV3M3> https://docs.google.com/spreadsheet/ccc?key=0AnXre3v9CjJXdDBUYk9qMlFuODV3M3




 <mailto:julee@adobe.com> julee@adobe.com







-----Original Message-----

From: Doug Schepers < <mailto:schepers@w3.org> schepers@w3.org>

Organization: W3C

Date: Wednesday, December 4, 2013 at 12:57 PM

To: WebPlatform Public List < <mailto:public-webplatform@w3.org> public-webplatform@w3.org>

Subject: Page Status Indicators

Resent-From: WebPlatform Public List < <mailto:public-webplatform@w3.org> public-webplatform@w3.org>

Resent-Date: Wednesday, December 4, 2013 at 12:57 PM


>Hi, folks–


>Last night, Eliezer Bernart (eliezerb) tackled one of our big

>outstanding actions (with my modest guidance): the page status markers.


>JuLee encouraged Eliezer to learn Semantic MediaWiki templates, given

>our dwindling resources there, and he really dived in. He asked for a

>specific task, and I suggested that he look at the outstanding flags



>As background, we've already discussed that many people find the large

>number of flags on a page (and their presentation) as intimidating and

>discouraging, both for reading and for editing. We had general (though

>imperfect) consensus that we should simplify the flags.


>On a related note, we also wanted to make sure sure that readers knew

>what content they could trust, and what was less complete or reliable.

>This dovetails with the initial goal for flags.


>Eliot proposed the following set of minimal flags to reflect the various

>content statuses:


>* Unconfirmed import

>* Needs review

>* Missing Content

>* Deletion/Move candidate

>* Contains Errors


>We agreed that this is one of the tasks that we needed completed before

>we announced the CSS milestone.


>Eliezer has run a test on the flags template in the /test wiki, removing

>the unwanted flags. If a page has any flags checked, it will show on the

>page [2]; if no flags are checked, it will not show any flag markers

>[3]. Once we get the wording settled, this should be a clear indicator

>of a page's readiness (or unreadiness).


>You can also see that this is much less intimidating to edit [4].


>Eliezer noted that if we change the flags template in the main wiki, we

>will lose all of the existing flags; I think this is unavoidable. He

>also explained that while he can set a flag as checked by default (e.g.

>"need review") for new pages, existing pages can't have any flags

>checked by default; so, we will need to find a way to efficiently check

>the "need review" flag for all pages we aren't confident about, so we

>can highlight the readiness of the CSS and certain API pages (maybe we

>could use a script to do this auto-checking?).


>I wanted to confirm with the community that this is the path we want to

>follow. What do you all think?


>Next steps:

>* clarify the wording used, to indicate that a page is not yet ready

>* settle on the visual appearance of flags (not critical, but nice to


>* deploy the new flags template on /wiki (the main content site)

>* make sure unready pages have a flag checked, and that ready pages are

>free from flags

>* rewrite the Getting Started and Editor's Guide pages to reflect the

>new flag statuses, per Scott's concern [5]





>Also, a big thanks to Eliezer! We should blog / tweet about this minor





> <http://lists.w3.org/Archives/Public/public-webplatform/2013Jun/0169.html> http://lists.w3.org/Archives/Public/public-webplatform/2013Jun/0169.html


> <http://lists.w3.org/Archives/Public/public-webplatform/2013Jun/0172.html> http://lists.w3.org/Archives/Public/public-webplatform/2013Jun/0172.html

>[2]  <http://docs.webplatform.org/test/css/properties/border-radius> http://docs.webplatform.org/test/css/properties/border-radius

>[3]  <http://docs.webplatform.org/test/dom/methods/getElementById> http://docs.webplatform.org/test/dom/methods/getElementById


> <http://docs.webplatform.org/t/index.php?title=css/properties/border-radius> http://docs.webplatform.org/t/index.php?title=css/properties/border-radius



> <http://lists.w3.org/Archives/Public/public-webplatform/2013Jul/0005.html> http://lists.w3.org/Archives/Public/public-webplatform/2013Jul/0005.html






Received on Wednesday, 4 December 2013 23:00:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:56 UTC