On 2016-09-03 07:54, H. Fox wrote:
On Fri, Sep 2, 2016 at 11:00 AM, Petko Yotov <5...@5ko.fr> wrote:
On 2016-08-31 22:10, H. Fox wrote:
On Wed, Aug 31, 2016 at 7:54 AM, Petko Yotov <5...@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
_______________________________________________
pmwiki-devel mailing list
pmwiki-devel@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
