+1 Cheap hallway testing is so incredibly useful that I dedicated my time in Berlin last year to giving a crash course in it. I am not sure it was effective in inspiring or educating people on how to do this, but everyone is welcome to revisit the slides here: http://wikitech.wikimedia.org/index.php?title=File:Trevor_Parscal_-_Wikimed… Yesterday we had our first "on our own" series of user tests, conducted by Parul Vora. While she is train in the kung-fu of user testing, she personally helped me put this set of slides together. I also pulled from my own experiences being involved in this kind of testing earlier in my career. My general pitch is, we should all be in the habit of doing whatever it takes to view users as they interact with our creations. I often use my wife, and now sometimes my 3-year old daughter to help me. Usually just showing someone a picture of a screen and asking "how would you do X?" is amazingly revealing. Higher-fidelity testing is great, but it's designed to squeeze the last bit of juice out of the lemon. In my experience the majority of it comes out quite easily in even the most causal of circumstances. My secondary pitch, which is not captured in these slides but was verbalized in Berlin was my view that we should user-test APIs with developers. This would especially be useful for our public HTTP API, but even PHP and JavaScript APIs could benefit from this. This differs from posting to the list and saying "does anyone have any better ideas". Instead we would design APIs around use-cases, and then observe users in those use-cases succeeding or failing. Bottom line - I know from experience that if we can even subtly introduce user testing as a factor in our decision making process, the impact will be amazing. - Trevor On 12/2/10 6:46 AM, Neil Kandalgaonkar wrote: _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Like, there's a thread over on Commons Village Pump right now about how to change certain strings that are hardcoded into the upload process. Apparently this kind of bug lasts for years rather than five minutes, just because the people who are most exercised about it don't have PHP skills or don't have commit access.

On Thu, Dec 2, 2010 at 5:17 PM, Paul Houle <paul(a)ontology2.com> wrote: What do you mean by "change the template of a mediawiki"? Do you mean templates in the MediaWiki sense, as in pages that can be transcluded into other pages? Or do you mean the skin? Skin HTML can usually be changed by just grepping a relevant class or id and editing some raw HTML, or a pretty simple wrapper layer. It can't be changed without hacking the code, so it's certainly a lot harder than in most popular web apps, but I'm pretty sure you can do it more easily in almost all cases than by postprocessing the HTML output.

On 10-12-02 04:52 PM, Platonides wrote: I was experimenting with an extension to make creating php-less skins possible myself. http://pastie.org/1343349<- here's Monobook ported to a template The biggest thing I see different from WordPress etc... is that there's a minimal amount of boilerplate in them. You don't have to copy the bottom boilerplate, there's no [dataAfterContent], you don't have things like our personal_urls where you have to code the whole tag manually calling to things to make tooltips, etc... and embedding code. The way the TOOLBOX has a bunch of stuff hardcoded into the skin isn't good. And IMHO those footerlinks should be part of MediaWiki instead of hardcoded into the skin. I wanted to make them part of the code, using an array in vector's style, making monobook use it, but fold it onto one line. Unfortunately I was stopped when I noticed that Vector moved tagline from the end, to the end of the first array, after copyright meaning they couldn't use the same array to get the same result.

Perhaps I should commit what I have so far even though it's not quite ready for use yet. It's enough to do this so far: http://testwiki.new.wiki-tools.com/index.php?title=Main_Page&useskin=te… ((this runs off that ported monobook template I put in the pastie)) Right now I'm using smarty's eval: which I don't want to use because it re-compiles the template each time you run it. I really wanted to make use of MediaWiki's caching system because MW already has such a good caching system it's built in, and having to require extra permissions just to make smarty happy felt messed up. I have a bad habit of starting projects for fun and experimenting them, then abandoning them later. The ones I finish are usually the ones with company backing, the really really simple ones, or ones with some other sort of backing or other people working on it to. So having someone else working on it too would probably be motivating. This came after experimenting with porting Wikia's Monaco skin (got 1/3 the way through), and after it I even started experimenting with writing an entire language embedded in php that could be used in MW. And there's my long lived vm based wiki farm experiment. One possibility I suppose, would be to use the vector array as the standard, but hardcode monobook to flatten it and relocate the tagline. Some ideas for the templates besides fixing caching... We should consider a method of doing personal_urls and whatnot using some blocks or functions that can aide in the generation of the links and make them simpler to build with tooltips and whatnot. Perhaps also some sort of block for content to automatically place the dataAfterContent. The sidebar block could be made better potentially. Besides footer_links we could also consider moving most of the toolbox out of monobook and whatnot. Converting it mostly into something you can loop through. Btw, the new powered by icon, using a little more rounded and fancy background: http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/images/… Anyone else think it feels slightly out of place in monobook? http://en.wikipedia.org/wiki/?useskin=monobook I debated tweaking the poweredby, etc... buttons to instead use something a little more component style, where the content of the button is an image, but the bg is provided by the skin. Giving you the same style as before in monobook, but that nice new fancy style in vector. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] On 10-12-03 11:10 AM, Trevor Parscal wrote: > This is a really awesome project, I'm sure we can figure out a way for > Vector and Monobook to be able to use the same arrays. > > Let me know if you want some help. > > - Trevor > > On 12/2/10 6:30 PM, Daniel Friesen wrote: > >> On 10-12-02 04:52 PM, Platonides wrote: >> >>> Aryeh Gregor wrote: >>> >>> >>>> On Thu, Dec 2, 2010 at 5:17 PM, Paul Houle&lt;paul(a)ontology2.com&gt; wrote: >>>> >>>> >>>>> Of all the code I've seen, the Mediawiki code seems to be one of >>>>> the most difficult code bases to make simple changes in. When I had to >>>>> change the template of a mediawiki once, the easiest answer I found was >>>>> to put a proxy server in front of it, drop out the original template >>>>> and spit the body text into a new template. (That said, this was a >>>>> system I already had on the shelf that worked wonders for all sorts of >>>>> commercial crapware) >>>>> >>>>> >>>> What do you mean by "change the template of a mediawiki"? Do you mean >>>> templates in the MediaWiki sense, as in pages that can be transcluded >>>> into other pages? Or do you mean the skin? Skin HTML can usually be >>>> changed by just grepping a relevant class or id and editing some raw >>>> HTML, or a pretty simple wrapper layer. It can't be changed without >>>> hacking the code, so it's certainly a lot harder than in most popular >>>> web apps, but I'm pretty sure you can do it more easily in almost all >>>> cases than by postprocessing the HTML output. >>>> >>>> >>> Seems a Usability failure at developer users level. >>> The proxying solution is completely wrong, yet WMF did it, too. >>> And looking at http://www.mediawiki.org/wiki/Manual:Skinning it isn't >>> friendly unless you already know what's it about. >>> >>> >> I was experimenting with an extension to make creating php-less skins >> possible myself. >> http://pastie.org/1343349<- here's Monobook ported to a template >> >> The biggest thing I see different from WordPress etc... is that there's >> a minimal amount of boilerplate in them. You don't have to copy the >> bottom boilerplate, there's no [dataAfterContent], you don't have things >> like our personal_urls where you have to code the whole tag manually >> calling to things to make tooltips, etc... and embedding code. The way >> the TOOLBOX has a bunch of stuff hardcoded into the skin isn't good. And >> IMHO those footerlinks should be part of MediaWiki instead of hardcoded >> into the skin. I wanted to make them part of the code, using an array in >> vector's style, making monobook use it, but fold it onto one line. >> Unfortunately I was stopped when I noticed that Vector moved tagline >> from the end, to the end of the first array, after copyright meaning >> they couldn't use the same array to get the same result. >> >>

PHP -> XSL doesn't quite feel like much of an improvement in terms of cutting down on the verbose redundant code boilerplate required to insert something. ie:<xsl:value-of select="title"/> doesn't look much better than<?php $this->text("title") ?>, as opposed to {$title|escape:html}. And I'm not sure how XSL handles html vs. text, we have stuff you want to htmlescape and stuff you want to output raw. Using an XSL lib also doesn't play nicely with things like calling a function to generate tooltips or fetch something from the i18n system. Unfortunately I think any designer we can convince to build a MediaWiki skin will probably dislike using XSL as a template language more than using PHP as a template language. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] On 10-12-06 07:57 AM, Trevor Parscal wrote: > Have you considered using something like say XSL? If a skin was a > combination of a set of CSS/JS/image files plus an XSL file which took > XML data (which would be the page content and various user interface > elements) then you could avoid using a whole new template system. PHP 5 > has an XSL 1.0 library compiled by default, and since it's implemented > in C, I would bet it's far more performant than any PHP implementation > of a template system aside from using PHP itself as a template system. > > Then again, there's a lot of people out there that dislike XSL for all > sorts of reasons - which to me have always carried the ring of > prejudice. I personally think XSL is awesome, and would defend it with > vigor. > > In any case, I'm excited about the work you are doing. > > - Trevor > > On 12/3/10 5:49 PM, Daniel Friesen wrote: > >> Perhaps I should commit what I have so far even though it's not quite >> ready for use yet. >> >> It's enough to do this so far: >> http://testwiki.new.wiki-tools.com/index.php?title=Main_Page&useskin=te… >> ((this runs off that ported monobook template I put in the pastie)) >> >> Right now I'm using smarty's eval: which I don't want to use because it >> re-compiles the template each time you run it. >> I really wanted to make use of MediaWiki's caching system because MW >> already has such a good caching system it's built in, and having to >> require extra permissions just to make smarty happy felt messed up. >> >> >> I have a bad habit of starting projects for fun and experimenting them, >> then abandoning them later. The ones I finish are usually the ones with >> company backing, the really really simple ones, or ones with some other >> sort of backing or other people working on it to. So having someone else >> working on it too would probably be motivating. >> This came after experimenting with porting Wikia's Monaco skin (got 1/3 >> the way through), and after it I even started experimenting with writing >> an entire language embedded in php that could be used in MW. And there's >> my long lived vm based wiki farm experiment. >> >> >> One possibility I suppose, would be to use the vector array as the >> standard, but hardcode monobook to flatten it and relocate the tagline. >> >> Some ideas for the templates besides fixing caching... We should >> consider a method of doing personal_urls and whatnot using some blocks >> or functions that can aide in the generation of the links and make them >> simpler to build with tooltips and whatnot. Perhaps also some sort of >> block for content to automatically place the dataAfterContent. The >> sidebar block could be made better potentially. >> Besides footer_links we could also consider moving most of the toolbox >> out of monobook and whatnot. Converting it mostly into something you can >> loop through. >> >> >> Btw, the new powered by icon, using a little more rounded and fancy >> background: >> http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/images/… >> Anyone else think it feels slightly out of place in monobook? >> http://en.wikipedia.org/wiki/?useskin=monobook >> I debated tweaking the poweredby, etc... buttons to instead use >> something a little more component style, where the content of the button >> is an image, but the bg is provided by the skin. Giving you the same >> style as before in monobook, but that nice new fancy style in vector. >> >> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] >> >> >> On 10-12-03 11:10 AM, Trevor Parscal wrote: >> >>> This is a really awesome project, I'm sure we can figure out a way for >>> Vector and Monobook to be able to use the same arrays. >>> >>> Let me know if you want some help. >>> >>> - Trevor >>> >>> On 12/2/10 6:30 PM, Daniel Friesen wrote: >>> >>> >>>> On 10-12-02 04:52 PM, Platonides wrote: >>>> >>>> >>>>> Aryeh Gregor wrote: >>>>> >>>>> >>>>> >>>>>> On Thu, Dec 2, 2010 at 5:17 PM, Paul Houle&lt;paul(a)ontology2.com&gt; wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Of all the code I've seen, the Mediawiki code seems to be one of >>>>>>> the most difficult code bases to make simple changes in. When I had to >>>>>>> change the template of a mediawiki once, the easiest answer I found was >>>>>>> to put a proxy server in front of it, drop out the original template >>>>>>> and spit the body text into a new template. (That said, this was a >>>>>>> system I already had on the shelf that worked wonders for all sorts of >>>>>>> commercial crapware) >>>>>>> >>>>>>> >>>>>>> >>>>>> What do you mean by "change the template of a mediawiki"? Do you mean >>>>>> templates in the MediaWiki sense, as in pages that can be transcluded >>>>>> into other pages? Or do you mean the skin? Skin HTML can usually be >>>>>> changed by just grepping a relevant class or id and editing some raw >>>>>> HTML, or a pretty simple wrapper layer. It can't be changed without >>>>>> hacking the code, so it's certainly a lot harder than in most popular >>>>>> web apps, but I'm pretty sure you can do it more easily in almost all >>>>>> cases than by postprocessing the HTML output. >>>>>> >>>>>> >>>>>> >>>>> Seems a Usability failure at developer users level. >>>>> The proxying solution is completely wrong, yet WMF did it, too. >>>>> And looking at http://www.mediawiki.org/wiki/Manual:Skinning it isn't >>>>> friendly unless you already know what's it about. >>>>> >>>>> >>>>> >>>> I was experimenting with an extension to make creating php-less skins >>>> possible myself. >>>> http://pastie.org/1343349<- here's Monobook ported to a template >>>> >>>> The biggest thing I see different from WordPress etc... is that there's >>>> a minimal amount of boilerplate in them. You don't have to copy the >>>> bottom boilerplate, there's no [dataAfterContent], you don't have things >>>> like our personal_urls where you have to code the whole tag manually >>>> calling to things to make tooltips, etc... and embedding code. The way >>>> the TOOLBOX has a bunch of stuff hardcoded into the skin isn't good. And >>>> IMHO those footerlinks should be part of MediaWiki instead of hardcoded >>>> into the skin. I wanted to make them part of the code, using an array in >>>> vector's style, making monobook use it, but fold it onto one line. >>>> Unfortunately I was stopped when I noticed that Vector moved tagline >>>> from the end, to the end of the first array, after copyright meaning >>>> they couldn't use the same array to get the same result. >>>> >>>> >>>>

One thing our skin system "does" have is an extensive linker and system for building tooltips and accesskeys for things using our i18n system. And calls to the message system from skins are all over the place: tagline, jumpto, and basically every header that's part of a skin itself is all generated by calls to the i18n system, they are not hardcoded in SkinTemplate.

PHP -> XSL doesn't quite feel like much of an improvement in terms of cutting down on the verbose redundant code boilerplate required to insert something. ie: <xsl:value-of select="title"/> doesn't look much better than <?php $this->text("title") ?>, as opposed to {$title|escape:html}.

And I'm not sure how XSL handles html vs. text, we have stuff you want to htmlescape and stuff you want to output raw. Using an XSL lib also doesn't play nicely with things like calling a function to generate tooltips or fetch something from the i18n system.

Unfortunately I think any designer we can convince to build a

skin will probably dislike using XSL as a template language more than using PHP as a template language.

Daniel Friesen wrote: This seems an argument for using the preprocessor for the skin system, in order to include the variables into the raw html.

Daniel Friesen wrote: This seems an argument for using the preprocessor for the skin system, in order to include the variables into the raw html. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Tue, Dec 7, 2010 at 5:12 PM, Trevor Parscal&lt;tparscal(a)wikimedia.org&gt; wrote: I was first like wtf as well, but on the other hand this way skin building would be much more accesibles for non-programmer mediawiki users. Regular wiki users do know wikitext, as opposed to PHP. I'm not entirely sure though that this would be good for your sanity. I wouldn't discard the idea immediately, insane as it may seem.

Daniel Friesen wrote: I'm not sure myself of the sanity of such approach. :) But if {$title|escape:html} is considered "friendly", it'd be much better to use a known syntax than creating a new one.

On 06/12/10 16:57, Trevor Parscal wrote: I love XSL too. Probably the easiest way to render an XML data file. Another approach could be inspired by ruby on rails way. You define a general application layout using HTML with special directives such as: <html> <body> <%= yield %> </body></html> "yield" is where the current view should be inserted. This mean a graphist / skinner, just have to know about HTML/CSS :-b To create your view, you use rhtml (ruby html) which is plain HTML in which you can insert ruby code using<% %> or<%= %> : <html><table> <% @articles.each do |article| %> <tr> <td><%= article.title %></td> <td><%= link_to 'Show', article</td> <td><%= link_to 'Edit', edit_path( article )</td> </tr> </table></html> It does make thing easier, since the whole backend is hidden. Its role is just to provide the correct variables (in the above case 'article' which is an array of articles objects). I think Symfony, now a day a popular PHP framework, use this system as well. [1] http://www.symfony-project.org/

* Ashar Voultoiz&lt;hashar+wmf(a)free.fr&gt; [Tue, 07 Dec 2010 19:19:53 +0100]: It's easy only when XSL style sheet already exists. Even simple loops were not so easy to peform in that language, at least in old v1.0 I've used some years ago. And expressions enclosed in tags are bloated. XQuery has easy loops and much less bloat, however it's much less supported in PHP.

I warned that I would defend XSL with vigor :)

Like, there's a thread over on Commons Village Pump right now about how to change certain strings that are hardcoded into the upload process. Apparently this kind of bug lasts for years rather than five minutes, just because the people who are most exercised about it don't have PHP skills or don't have commit access.