[pmwiki-devel] SkinTest page for developers

Thu Sep 8 14:07:25 CDT 2016

On 2016-09-03 07:54, H. Fox wrote:
> On Fri, Sep 2, 2016 at 11:00 AM, Petko Yotov <5ko at 5ko.fr> wrote:
>> On 2016-08-31 22:10, H. Fox wrote:
>>> 
>>> On Wed, Aug 31, 2016 at 7:54 AM, Petko Yotov <5ko at 5ko.fr> wrote:
>>>> 
>>>> Your SkinTestAssortment page is a good start in that direction 
>>>> (thanks!),
>>>> so
>>>> for the moment I linked to it from the SkinsHeader page.
>>> 
>>> Would it be even easier to have a separate page like Skins/SkinTest
>>> that includes the Compact page?
>> 
>> There is no problem if a selected compact set of markups is included 
>> as a
>> first section.
> 
> On further thought, the same page could be both compact and
> comprehensive. The compact stuff just needs to be at the top.
> 
> Links to test other skins should be immediately below the compact
> portion (like they are). Anything else could be below the test-a-skin
> links.
> 
> Even all the content from the other test page can go below the links, I 
> suppose.

I agree.

>>> What about links in the list that are:
>>> 
>>> * Old skins that are broken?
>> 
>> If I'm a webmaster I'd like to see that the skin is broken before
>> downloading it.
> 
> Agreed!
> 
> That's why I put the Compact test link and also links to test for
> valid HTML, CSS, and RWD in the SkinsHeader.
> 
> Regarding the SkinsHeader, the purpose-built [[SkinTest-Compact]] page
> seems more appropriate than [[Test/SkinTestAssortment]] there. Why did
> you switch?!

You seemed to want to have the compact page you created stay as you 
wanted. I explained why as a webmaster I need to see and test more than 
that. I don't want to fight, so I reverted your page as you wanted, but 
simply redirected the link to the more appropriate page.

Note that the subject you chose for this thread is "SkinTest page for 
developers" (I assume skin developers). But the listings and the test 
page are not for skin developers, they are for webmasters.

Following the changes you suggested, I agree with you that a combined 
page, with the compact markup samples at the top, the list of links to 
other skins below it, and an extensive (and extensible) sample of core 
markups below, could be suitable to both the hypothetical 
"attention-deficient webmasters" you mentioned, and the more 
focused/curious/patient ones.

I would probably place the links to the various sections where they are 
more easily noticed, like in a bulleted list or in a frame, not at the 
end of the compact section sentences. Maybe a table of contents would be 
best.

>>> * Skins that aren't installed?
>> 
>> They should be installed (when I find the free time to review them), 
>> unless
>> if I notice some security issues, or blatant spam, or something else 
>> that
>> should not be in a recipe.
> 
> Thanks for doing that. Much appreciated!
> 
> I was referring to some skins that aren't installed (and won't be)
> that are in the list.

I assume these are those containing security issues, or blatant spam, or 
something else that should not be in a recipe. I am open to suggestions 
as to what they should become.

>>> * Links that aren't skins at all?
>> 
>> When we split the Cookbook group to the Skins group, people insisted 
>> that
>> not only skins, but any and all recipes related to skins should be 
>> there,
>> and moved these non-skin, but skin-related recipes from the Cookbook 
>> to
>> Skins. Indeed, this now makes it more complex to create an automatic 
>> list of
>> links. But there are several ways to do it: either add a negative 
>> name=
>> parameter to the pagelist like
>>    (:pagelist group=Skins name=-NeitherASkin,-NorASkin:)
>> 
>> or, use a negative keyword inside the non-skin recipes, e.g.  
>> (:comment
>> not_a_skin:) then subtract these pages with a negative search like
>>    (:pagelist group=Skins -not_a_skin:)
>> 
>> or add the [[!Skins]] category to actual skins, and only to them, and 
>> use
>>   (:pagelist group=Skins link=Category.Skins:)
> 
> ...or something like [[!SkinsTestList]] or [[!SkinsTestInclude]], and
> add that to the template so newly posted skins get included
> automagically.

As there are many more skins than non-skins in the Skins group, it 
should be easier to tag the non-skins for exclusion. But this is only a 
detail, there are many possible solutions.

> Regarding "why bother curating?"...
> 
> The reason a curated list is better is because when people are given
> too many choices sometimes they choose not choose at all.

So you feel they would keep the default skin? I don't mind this. :-)

My observation is that they would probably compose their own skin. A few 
years back I've followed all links from SuccessStories and PmWikiUsers 
to take screenshots: a large part of the linked wikis had custom skins 
and layouts, something I found exciting.

> In particular, some webmasters may be "maximizers" (as opposed to
> "satisficers") who will experience psychological stress when given too
> many choices. Sometimes less is more.
> 
>    https://en.wikipedia.org/wiki/The_Paradox_of_Choice
> 
> Put another way: "Avoid information overload for best results."

I've read this book, but I'm not sure it should apply here. Otherwise we 
would want to curate the Cookbook where there are 1200+ recipes. Or the 
documentation, where there are hundreds of documented variables and 
options (or curate the core - to get rid of the options).

Webmasters/administrators are extremely motivated people, focused on the 
needs for their websites. I wouldn't underestimate them -- they are 
capable of keeping their attention as long as they have to, or need to.

What could benefit PmWiki is further simplifications for users (writers) 
who contribute occasionally to their wiki. But this is another subject.

Petko

---
Change log     :  http://www.pmwiki.org/wiki/PmWiki/ChangeLog
Release notes  :  http://www.pmwiki.org/wiki/PmWiki/ReleaseNotes
If you upgrade :  http://www.pmwiki.org/wiki/PmWiki/Upgrades