Re: [Wikitech-l] Making usability part of the development process
On 10-12-07 04:32 PM, Platonides wrote:
Daniel Friesen wrote:
On 10-12-07 08:18 AM, Bryan Tong Minh 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.
^_^ I was drafting a response Platonides' comment, ie: an example of a
chunk of MonoBook code using a WikiText style template language... in
order to demonstrate the insanity of using the style that our
preprocessor preprocesses as a template language for skins...
I decided it sounded obviously insane enough that I didn't need to...
;) wan't me to re-start that example...?
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
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.
;) that's Smarty, it is a known syntax.
json-template would be {title|html-attr-value}, not much better.
By the way, I managed to create an absolutely horrid
preg_replace_callback based syntax:
h3 id=siteSub{msg:tagline}/h3
div
id=contentSub{h:userlangattributes}{h:subtitle}/div{ifdata:undelete|x1x|
div id=contentSub2{h:undelete}/div|x1x}
!-- start content --
{h:bodytext}
{h:catlinks}
!-- end content --
ul
{foreachdata:content_actions:tab|x1x| li{ifdata:tab.class|x2x|
class={t:tab.class}|x2x}a href={t:tab.href}{t:tab.text}/a/li
|x1x} /ul
It works...! I'm just waiting on finishing up my abstraction of the
sidebar to finish up a port of MonoBook to it. And the code that handles
the syntax is even less than 100 lines.
The idea is that whatever known or unknown syntax we come up with, we
can compile it to this syntax and not have to re-parse the template
source each time, and not have to deal with compiling to php which could
have php injection vulnerabilities.
Now, as for a known or unknown syntax, what's the friendliest syntax
for outputting variables with and without html escaping you can think of?
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
On 12/7/10 10:46 PM, Dmitriy Sintsov wrote: * Ashar Voultoizhashar+...@free.fr [Tue, 07 Dec 2010 19:19:53 +0100]: On 06/12/10 16:57, Trevor Parscal wrote: I personally think XSL is awesome, and would defend it with vigor. I love XSL too. Probably the easiest way to render an XML data file. 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. Loops? Maybe you weren't using XSL the way it's meant to be used? In XSL templates are just applied to the data. Consider the case of mixed node types within a common parent... !-- given this data -- root child name=a / something-else name=d / child name=b / child name=c / /root !-- using this stylesheet -- xsl:template name=root ulxsl:apply-templates //ul /xsl:template xsl:template name=child lixsl:value-of select=@name //li /xsl:template xsl:template name=something-else listrongxsl:value-of select=@name //strong/li /xsl:template !-- resulting output would be -- ul lia/li listrongd/strong/li lib/li lic/li /ul I warned that I would defend XSL with vigor :) - Trevor ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
* Trevor Parscal tpars...@wikimedia.org [Wed, 08 Dec 2010 07:31:33 -0800]: On 12/7/10 10:46 PM, Dmitriy Sintsov wrote: * Ashar Voultoizhashar+...@free.fr [Tue, 07 Dec 2010 19:19:53 +0100]: On 06/12/10 16:57, Trevor Parscal wrote: I personally think XSL is awesome, and would defend it with vigor. I love XSL too. Probably the easiest way to render an XML data file. 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. Loops? Maybe you weren't using XSL the way it's meant to be used? In XSL templates are just applied to the data. Consider the case of mixed node types within a common parent... !-- given this data -- root child name=a / something-else name=d / child name=b / child name=c / /root !-- using this stylesheet -- xsl:template name=root ulxsl:apply-templates //ul /xsl:template xsl:template name=child lixsl:value-of select=@name //li /xsl:template xsl:template name=something-else listrongxsl:value-of select=@name //strong/li /xsl:template !-- resulting output would be -- ul lia/li listrongd/strong/li lib/li lic/li /ul I warned that I would defend XSL with vigor :) I was talking about using recursion to generate repeated content: http://www.ibm.com/developerworks/xml/library/x-tiploop.html You are right that XSL is powerful and worth, however it didn't gain huge popularity despite being invented many years ago. The source code is not well readable and too long due to embedding of language constructions in tags. However, MediaWiki probably would be OK to use it, because many of MediaWiki users are advanced users and scientists. Ordinary people would be scared of both wiki parser templates and XSL. XQuery is probably under development and not ready yet. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
On 08/12/10 16:31, Trevor Parscal wrote: I warned that I would defend XSL with vigor :) Magnus wrote a wiki to XML converter a few years ago and I hacked up a small XSLT to convert its output to XHTML: http://svn.wikimedia.org/viewvc/mediawiki/trunk/parsers/wiki2xml/php/ Look at test.xml xhtml.xslt :p -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
On 12/7/2010 2:23 AM, Daniel Friesen wrote: 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. And that's the rub. I18N is essential if you need to cover multiple linguistic zones. If you don't, I18N can increase the cost of making simple changes by a factor of 3 to 5. I was working on a product aimed at the Brazillian market (pt-br) years ago, and the first iteration of the product was I18N'ed to the sky because we wanted to get investment from the en, es and pt-br zones. Well, that investment didn't come, we bootstrapped, and the first version to really hit the web was built exclusively for the pt-br zone. Instead of requiring a committee to meet and wasting hours just to move a button from one place to another, we could just do it. If your resources aren't infinite, I18N can have a definitely harmful effect on UI quality because it tries to break your hands every time you want to make a tweak. As for XSLT, it's one of those languages that can't decide if it wants to be Turing complete or not. XSLT, as an output templating language, is the kind of thing that takes a task an intern can do in five minutes and makes it a job that you have to bring a consultant in for three weeks. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
Daniel Friesen wrote:
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}.
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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
On Tue, Dec 7, 2010 at 4:26 PM, Platonides platoni...@gmail.com wrote:
Daniel Friesen wrote:
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}.
This seems an argument for using the preprocessor for the skin system,
in order to include the variables into the raw html.
Skin sytem in wikitext?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
Bryan Tong Minh wrote:
On Tue, Dec 7, 2010 at 4:26 PM, Platonides platoni...@gmail.com wrote:
Daniel Friesen wrote:
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}.
This seems an argument for using the preprocessor for the skin system,
in order to include the variables into the raw html.
Skin sytem in wikitext?
Only the preprocessing.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
Oh please no!
- Trevor
On 12/7/10 7:26 AM, Platonides wrote:
Daniel Friesen wrote:
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}.
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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
On Tue, Dec 7, 2010 at 5:12 PM, Trevor Parscal tpars...@wikimedia.org wrote:
Oh please no!
- Trevor
On 12/7/10 7:26 AM, Platonides wrote:
Daniel Friesen wrote:
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}.
This seems an argument for using the preprocessor for the skin system,
in order to include the variables into the raw html.
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.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
On 10-12-07 08:18 AM, Bryan Tong Minh wrote:
On Tue, Dec 7, 2010 at 5:12 PM, Trevor Parscaltpars...@wikimedia.org wrote:
Oh please no!
- Trevor
On 12/7/10 7:26 AM, Platonides wrote:
Daniel Friesen wrote:
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}.
This seems an argument for using the preprocessor for the skin system,
in order to include the variables into the raw html.
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.
^_^ I was drafting a response Platonides' comment, ie: an example of a
chunk of MonoBook code using a WikiText style template language... in
order to demonstrate the insanity of using the style that our
preprocessor preprocesses as a template language for skins...
I decided it sounded obviously insane enough that I didn't need to...
;) wan't me to re-start that example...?
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
On 06/12/10 16:57, Trevor Parscal wrote: I personally think XSL is awesome, and would defend it with vigor. 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 %= % : htmltable % @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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
On Tue, Dec 7, 2010 at 9:46 AM, Paul Houle p...@ontology2.com wrote: I18N is essential if you need to cover multiple linguistic zones. If you don't, I18N can increase the cost of making simple changes by a factor of 3 to 5. Not for us, in my experience. The developers just write the stuff purely in English and then volunteers handle localization. The cost might technically be much higher, but it's mostly handled by volunteers, so it doesn't actually hurt much of anything. The only difference for developers is we have to put messages in their own file and refer to them with message functions, but it's not a noticeable cost once you get used to it. Also I guess we have to spend some time designing and optimizing the localization system, but that's only a small part of development, not a really big cost. In any event, MediaWiki being localizable is entirely non-negotiable at this point, so if there's a cost, we're going to pay it anyway. What sort of cost are you talking about here, though? I can't think what sort of i18n system would require simple UI changes to take three to five times the work. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
On 10-12-07 10:19 AM, Ashar Voultoiz wrote: On 06/12/10 16:57, Trevor Parscal wrote: I personally think XSL is awesome, and would defend it with vigor. 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%= % : htmltable % @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/ erb/rhtml/erubis/etc... is basically nearly the same thing as the ?php ? blocks we already use. Also, one of my goals is to provide templates which are php-less so that even environments like wiki farms can provide the ability for skins to be customized without worrying about php injection. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
Daniel Friesen wrote:
On 10-12-07 08:18 AM, Bryan Tong Minh 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.
^_^ I was drafting a response Platonides' comment, ie: an example of a
chunk of MonoBook code using a WikiText style template language... in
order to demonstrate the insanity of using the style that our
preprocessor preprocesses as a template language for skins...
I decided it sounded obviously insane enough that I didn't need to...
;) wan't me to re-start that example...?
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
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.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
* Ashar Voultoiz hashar+...@free.fr [Tue, 07 Dec 2010 19:19:53 +0100]: On 06/12/10 16:57, Trevor Parscal wrote: I personally think XSL is awesome, and would defend it with vigor. I love XSL too. Probably the easiest way to render an XML data file. 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. 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 %= % : htmltable % @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). Not bad. BTW, a good skin templating probably could also become an alternative wiki templating for wiki articles. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
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_Pageuseskin=testskin ((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/poweredby_mediawiki_88x31.png?revision=76120view=markup 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 Houlep...@ontology2.com 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
Re: [Wikitech-l] Making usability part of the development process
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_Pageuseskin=testskin
((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/poweredby_mediawiki_88x31.png?revision=76120view=markup
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 Houlep...@ontology2.com
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,
Re: [Wikitech-l] Making usability part of the development process
Fair enough, but when I've pushed for using PHP as a template language,
even with a clever wrapper that would make injected data escaped by
default (so unescaping was obvious and could be more easily scrutinized
for XSS) I have been met with about equal resistance.
The state of things is that unless you are generating HTML 100%
procedurally (such as by using the Xml and Html classes) then you are
seen as doing something wrong. Adding something like smarty to the
system seems silly when we have two completely reasonable alternatives
at our disposal already.
XSL allows data to be injected without escaping:
xsl:value-of select=. disable-output-escaping=yes /
This is good because it's escaped by default, and any use of this
attribute would be obvious and could thus be scrutinized for XSS.
As for hooking in an i18n system, I'm not so sure skins should really be
arbitrarily injecting messages anyways. What's the use case here?
Generating tooltips? I'm a bit lost there.
- Trevor
On 12/6/10 8:13 AM, Daniel Friesen wrote:
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_Pageuseskin=testskin
((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/poweredby_mediawiki_88x31.png?revision=76120view=markup
Anyone else think it feels slightly out of place in monobook?
http://en.wikipedia.org/wiki/?useskin=monobook
I debated tweaking the
Re: [Wikitech-l] Making usability part of the development process
* Daniel Friesen li...@nadir-seen-fire.com [Mon, 06 Dec 2010 08:13:04
-0800]:
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}.
XQuery code looks much less bloated, much like your last example {} :
http://en.wikipedia.org/wiki/XQuery
however I am not sure it is equally as powerful and probably is not well
supported in PHP :-(
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.
Also XSL wants tags to be properly closed, while in HTML5 they have
decided a human-friendly way of tag soup.
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.
I wonder whether XQuery is a good alternative but it seems it does not
catch up :-( The same was for XSL (XSL exists for ages, yet it didn't
gain a huge popularity - perhaps, because it's tiresome to type
statements in tags).
Dmitriy
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
input type='submit' name=go class=searchButton id=searchGoButton
value=?php $this-msg('searcharticle') ??php echo
$this-skin-tooltipAndAccesskey( 'search-go' ); ? /
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.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On 10-12-06 08:20 AM, Trevor Parscal wrote:
Fair enough, but when I've pushed for using PHP as a template language,
even with a clever wrapper that would make injected data escaped by
default (so unescaping was obvious and could be more easily scrutinized
for XSS) I have been met with about equal resistance.
The state of things is that unless you are generating HTML 100%
procedurally (such as by using the Xml and Html classes) then you are
seen as doing something wrong. Adding something like smarty to the
system seems silly when we have two completely reasonable alternatives
at our disposal already.
XSL allows data to be injected without escaping:
xsl:value-of select=. disable-output-escaping=yes /
This is good because it's escaped by default, and any use of this
attribute would be obvious and could thus be scrutinized for XSS.
As for hooking in an i18n system, I'm not so sure skins should really be
arbitrarily injecting messages anyways. What's the use case here?
Generating tooltips? I'm a bit lost there.
- Trevor
On 12/6/10 8:13 AM, Daniel Friesen wrote:
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_Pageuseskin=testskin
((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
Re: [Wikitech-l] Making usability part of the development process
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 Houlep...@ontology2.com 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. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
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_Pageuseskin=testskin ((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/poweredby_mediawiki_88x31.png?revision=76120view=markup 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 Houlep...@ontology2.comwrote: 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
Re: [Wikitech-l] Making usability part of the development process
+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_-_Wikimedia_Developers_Workshop_-_Berlin_2010.pdf 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: Hi there -- I don't post much here, but I was the programmer on the Multimedia Usability Project, which primarily focused on making uploads easier. The outside funding for that project just ended, so I think it's a good time to talk about what (if anything) we will do in the future along these lines. Going forward, we ought not to think about usability as the responsibility a few people in San Francisco. I have been asking myself how we could end the need for usability projects, and instead make that part of everyone's practices. What makes you a usability engineer? My personal belief is that it isn't (primarily) a matter of having special knowledge. You become a usability software engineer when you see five average users utterly fail to accomplish the task you wanted them to be able to accomplish. Programming is a hubristic enterprise, but for UI, these negative feelings are essential: watching ordinary users get angry and frustrated dealing with what you've created, even feeling a certain shame and embarassment that you got it so wrong. Only then do you see how large the conceptual gap is between you and the average user -- but you also usually come out of the experience with an immediate understanding of how to fix things. So is there a way to have *everybody* who develops software for end users in our community have that experience? Maybe. At the WMF, for these Usability Projects, we had to do formal studies with expert consultants, because these were grant-funded projects and we needed to present scientific data. Doing those studies is expensive and time-consuming. But as a developer, it was more valuable to do hallway usability testing in an informal way. There are lots of startups these days that try to deliver such lightweight user testing over the web; could we do the same? Or, possibly we don't even need software; maybe what we need is a tradition of doing this for everything we release. So how about that? If there were an easy way to integrate usability testing into your process as a developer, would you be interested? And what should that look like? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
I'd like to +1 all of this, particularly Trevor's thoughts on developer-testing APIs - or software that is otherwise meant to be extended/used by other developers. As a predominantly back-end developer, it's become clear to me over the last few years that usability is not just a front-end concern. 'Users' don't necessarily only interact with the 'front end'. Particularly in an open-source paradigm, 'users' need to be thought of much more broadly than just the person who clicks links on your website. If we ignore principles of usability at the back-end code level, we run the risk of writing software that is utterly useless to anyone other than ourselves. This not only defeats some of the purpose of OSS, it makes OSS that much more inaccessible all users - developers included. On 12/02/2010 10:35 AM, Trevor Parscal wrote: +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_-_Wikimedia_Developers_Workshop_-_Berlin_2010.pdf 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: Hi there -- I don't post much here, but I was the programmer on the Multimedia Usability Project, which primarily focused on making uploads easier. The outside funding for that project just ended, so I think it's a good time to talk about what (if anything) we will do in the future along these lines. Going forward, we ought not to think about usability as the responsibility a few people in San Francisco. I have been asking myself how we could end the need for usability projects, and instead make that part of everyone's practices. What makes you a usability engineer? My personal belief is that it isn't (primarily) a matter of having special knowledge. You become a usability software engineer when you see five average users utterly fail to accomplish the task you wanted them to be able to accomplish. Programming is a hubristic enterprise, but for UI, these negative feelings are essential: watching ordinary users get angry and frustrated dealing with what you've created, even feeling a certain shame and embarassment that you got it so wrong. Only then do you see how large the conceptual gap is between you and the average user -- but you also usually come out of the experience with an immediate understanding of how to fix things. So is there a way to have *everybody* who develops software for end users in our community have that experience? Maybe. At the WMF, for these Usability Projects, we had to do formal studies with expert consultants, because these were grant-funded projects and we needed to present scientific data. Doing those studies is expensive and time-consuming. But as a developer, it was more valuable to do hallway usability testing in an informal way. There are lots of startups these days that try to deliver such lightweight user testing over the web; could we do the same? Or, possibly we don't even need software; maybe what we need is a tradition of doing this for everything we release. So how about that? If there were an easy way to integrate usability testing into your process as a developer, would you be interested? And what should that look like? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org
Re: [Wikitech-l] Making usability part of the development process
On 12/2/10 11:05 AM, Arthur Richards wrote: As a predominantly back-end developer, it's become clear to me over the last few years that usability is not just a front-end concern. 'Users' don't necessarily only interact with the 'front end'. Particularly in an open-source paradigm, 'users' need to be thought of much more broadly than just the person who clicks links on your website. This is especially true of our projects. 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. We have all kinds of contributors who know how to hack one layer of the system but not others. That said, I think the deeper we go into the code, it becomes more about good documentation. At the outer layers things have to be more discoverable. -- Neil Kandalgaonkar ( ne...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Making usability part of the development process
Neil Kandalgaonkar wrote: 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. Not really. I had thought about it before without reaching to a Right Way to fix it. However, today I was inspired. http://www.mediawiki.org/wiki/Special:Code/MediaWiki/77623 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
