[Wikitech-l] Making usability part of the development process
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? -- Neil Kandalgaonkar ( ___ 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
+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
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 ( ___ 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/2/2010 2:48 PM, 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. I've done my time in maintainance programming hell. I've hacked on code by McArthur "geniuses" and some of the greatest computer scientists of our time. I've also had to clean up the messes left behind by people who should never be allowed anywhere near a computer. 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) That said, I spent a good deal of time this summer building an IX system that parses mediawiki markup and if I had to do it all again I would have braved the guantlet and embeded Mediawiki in it, because you can get closer to 100% correct processing of templates that way than you can by writing a recursive descent parsers and thousands of rules... ___ 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 Thu, Dec 2, 2010 at 5:17 PM, Paul Houle 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. ___ 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
Re: [Wikitech-l] Making usability part of the development process
Aryeh Gregor wrote: > On Thu, Dec 2, 2010 at 5:17 PM, Paul Houle 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. ___ 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/2/10 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 Heh, I attended that talk but completely forgot about it. ;) I was playing Portal again for kicks and looking at the developer commentary tracks. Portal spends a lot of time training users in a radically new gameplay concept. It's fascinating to hear all the tricks they used to get the player to learn things, as they played the game, almost without effort. http://www.youtube.com/watch?v=o1kvadcJwmE -- Neil Kandalgaonkar ( ___ 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-02 04:52 PM, Platonides wrote: > Aryeh Gregor wrote: > >> On Thu, Dec 2, 2010 at 5:17 PM, Paul Houle 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. -- ~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
2010/12/2 Paul Houle > > 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. I'm absolutely not a programmer (probably my profile is much more similar to someone "who should never be allowed anywhere near a computer") but sometimes I write some code to parse wiki markup. :-( I came to conclusion that most troubles come out from the fact that wiki markup is intrisecally "badly formed", just the opposite of a "well formed" code. The price of some tricks to build a "user-friendly" language (think only to the use of apostrophes to obtain italic and bold) is extremely high in terms of parsing complexity... another mess comes from mixing contents and attributes inside templates. But I have no hope that this can be fixed. Alex ___ 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
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 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_Page&useskin=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=76120&view=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 Houlewrote: >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
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_Page&useskin=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=76120&view=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 Houle 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 H
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: doesn't look much better than 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=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=76120&view=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 Houle >> wrote: >> >> >> >>> Of all the code I've seen, the Mediawiki code seems to be one >>> of
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: 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: doesn't look much better than $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=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=76120&view=markup >>> Anyone else think it feels slight
Re: [Wikitech-l] Making usability part of the development process
* Daniel Friesen [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: doesn't look much better than $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
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: > > > > 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: doesn't look much better than> $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=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
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: doesn't look much better than $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 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: doesn't look much better than > $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 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: doesn't look much better than >> $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: doesn't look much better than> $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 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: doesn't look much better than>> $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 Parscal 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:doesn't look much better than>>> $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: <%= yield %> "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 <%= %> : <% @articles.each do |article| %> <%= article.title %> <%= link_to 'Show', article <%= link_to 'Edit', edit_path( article ) 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 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: > > > > <%= yield %> > > > "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<%= %> : > > > <% @articles.each do |article| %> > > <%= article.title %> > <%= link_to 'Show', article > <%= link_to 'Edit', edit_path( article ) > > > > 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 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 [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: > > > ><%= yield %> > > > "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 <%= %> : > > > <% @articles.each do |article| %> > > <%= article.title %> > <%= link_to 'Show', article > <%= link_to 'Edit', edit_path( article ) > > > > 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
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: {msg:tagline} {h:subtitle}{ifdata:undelete|x1x| {h:undelete}|x1x} {h:bodytext} {h:catlinks} {foreachdata:content_actions:tab|x1x| {t:tab.text} |x1x} 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 Voultoiz [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... a d b c 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 [Wed, 08 Dec 2010 07:31:33 -0800]: > On 12/7/10 10:46 PM, Dmitriy Sintsov wrote: > > * Ashar Voultoiz [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... > > > > > > > > > > > > > > > > > > > > > > > a > d > b > c > > > 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