Re: [Wikitech-l] The future of skins

[svetlana]

Niklas Laxström wrote:
> At this point about everyone needs templating library as soon as
> possible and do not want to get blocked by the RFC. Please, let's all
> work together to complete the RFC for the benefit of everyone.
> 
>   -Niklas

I've opened https://www.mediawiki.org/wiki/Category:All_skins . I am in the 
process of notifying each skin maintainers of this RfC immediately.

svetlana

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The future of skins

[S Page]

On Wed, Aug 27, 2014 at 12:17 AM, Antoine Musso  wrote:

> Le 27/08/2014 08:59, Niklas Laxström a écrit :
> > At this point about everyone needs templating library as soon as
> > possible and do not want to get blocked by the RFC.
>

You can use Handlebars templates, implemented by Lightncandy in PHP and
provided as ResourceLoader modules by the Mantle extension.[1]  Tested,
working, passed security review, fast according to the table in the
templating RFC.  Flow uses the same templates in both PHP and JS, though of
course we have to implement helper functions in both languages.

There are genuine benefits to Gabriel Wicke's Knockoff-Tassembly
approach[2] including DOM-based templating and reactive updates in
JavaScript if you use full knockout.js.  So the Flow team hasn't been
involved in the RFC, assuming that Knockoff-Tassembly will be the eventual
approach. Are we now reevaluating?

As I understand Jon summary, the idea is a proof of concept based on
> Mustache that would be out of mediawiki/core.  Any experience acquired in
> that experiment would help move forward the HTML templating library RFC in
> one way (twig) or an other (mustache).
>

AIUI I don't see much win in mustache. It's not faster and does less than
handlebars. Twig/Swig does more (macros, parent, extends, more?) which can
result in worse separation of concerns.

"There can be only one" (Highlander), or two or three in the meantime :-)
Cheers,

[1] https://www.mediawiki.org/wiki/Extension:Mantle#Templates
[2]
https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library/Knockoff_-_Tassembly

--
=S Page  Features engineer
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The future of skins

[svetlana]

Hi,

On Wed, 27 Aug 2014, at 16:59, Niklas Laxström wrote:
> 2014-08-27 1:53 GMT+03:00 Jon Robson :
> > 2) We need a templating system in core. Trevor is going to do some
> > research on server side templating systems. We hope that the
> > templating RFC [1] can get resolved however we are getting to a point
> > that we need one as soon as possible and do not want to be blocked by
> > the outcome of this RFC, especially given a mustache based templating
> > language can address all our current requirements.
> >
> > [1] 
> > https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
> 
> At this point about everyone needs templating library as soon as
> possible and do not want to get blocked by the RFC. Please, let's all
> work together to complete the RFC for the benefit of everyone.
> 
>   -Niklas

I'm not very familiar with the topic.
1) Which of those involve clear separation of PHP and HTML, so that editing 
layout only involves editing a file with markup?
2) Which of those are closer to MVC approach?
3) How many of the currently deployed extensions have the features mentioned 
above (uploadwizard, flow, etc) making it easy for a designer (not a 
programmer) to edit how they look and what their layout is?

svetlana

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki Security and Maintenance Releases: 1.22.10 and 1.23.3

[Markus Glaser]

Hello everyone,

I would like to announce the release of MediaWiki 1.22.10 and 1.23.3. This is a 
regular maintenance release. Download links are given at the end of this email. 

== Bugfixes in 1.23.3 ==
* (bug 68501) Correctly handle incorrect namespace in cleanupTitles.php.
* (bug 64970) Fix support for blobs on DatabaseOracle::update.
* (bug 66574) Display MediaWiki:Loginprompt on the login page.
* (bug 67870) wfShellExec() cuts off stdout at multiples of 8192 bytes.
* (bug 60629) Handle invalid language code gracefully in 
  Language::fetchLanguageNames.
* (bug 62017) Restore the number of rows shown on Special:Watchlist.
* Check for boolean false result from database query in SqlBagOStuff.

== Bugfixes in 1.22.10 ==
* (bug 64970) Fix support for blobs on DatabaseOracle::update

Full release notes for 1.23.3:


Full release notes for 1.22.10:


Public keys:


**
1.23.3
**
Download:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.3.tar.gz

Patch to previous version (1.23.2):
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.3.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.3.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.3.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.3.patch.gz.sig

Note:
There is no i18n patch as there are no changes in translation.

**
1.22.10
**
Download:
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.10.tar.gz

Patch to previous version (1.22.9):
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.10.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-core-1.22.10.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.10.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.10.patch.gz.sig

Note:
There is no i18n patch as there are no changes in translation.


Markus Glaser
(Wiki Release Team)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] The future of skins

[Monte Hurd]

I've finished the SVGs-to-font and font-to-SVGs scripts. I'll document and
post these in the next couple days.


On Wed, Aug 27, 2014 at 2:26 PM, Trevor Parscal 
wrote:

> Someone in the meeting also claimed that Swig and Twig were compatible,
> and that does appear to be generally true, but I think there are some
> deviations.
>
> - Trevor
>
>
> On Wed, Aug 27, 2014 at 1:39 PM, Juliusz Gonera 
> wrote:
>
>> Someone in one of our meetings mentioned that Twig is a PHP
>> implementation of Mustache. This doesn't seem to be the case though.
>> We need a templating solution that works both on the server and the
>> client.
>>
>> On Tue, Aug 26, 2014 at 5:21 PM, Trevor Parscal 
>> wrote:
>> > Thanks for summarizing the meeting Jon.
>> >
>> > So, let's get Twig/Swig into core then, eh? :)
>> >
>> > - Trevor
>> >
>> >
>> > On Tue, Aug 26, 2014 at 3:53 PM, Jon Robson 
>> wrote:
>> >>
>> >> Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and
>> >> talked about the future of skins. Hopefully this mail summarises what
>> >> we talked about and what we agreed on. Feel free to add anything, or
>> >> ask any questions in the likely event that I've misinterpreted
>> >> something we talked about or this is unclear :)
>> >>
>> >> Specifically we talked about how we are unhappy with how difficult it
>> >> currently is for developers to create a skin. The skin class involves
>> >> too many functions and does more than a skin should do e.g. manage
>> >> classes on the body, worry about script tags and style tags.
>> >>
>> >> Trevor is going to create a base set of widgets, for example a list
>> >> generator to generate things like a list of links to user tools. The
>> >> widgets will be agnostic to how they are rendered - some may use
>> >> templates, some may not.
>> >>
>> >> We identified the new skin system will have two long term goals:
>> >> 1) We would like to get to the point where a new skin can be built by
>> >> simply copying and pasting a master template and writing a new css
>> >> file.
>> >> 2) Should be possible for us in future to re-render an entire page via
>> >> JavaScript and using the modern history push state re-render any page
>> >> via the API. (Whether we'd want to do this is another consideration
>> >> but we would like to have an architecture that is powerful enough to
>> >> support such a thing)
>> >>
>> >> As next steps we agreed to do the following:
>> >>
>> >> 1) Trevor is going to build a watch star widget on client and server.
>> >> We identified that the existing watch star code is poorly written and
>> >> has resulted in MobileFrontend rewriting it. We decided to target this
>> >> as it is a simple enough example that it doesn't need a template. It's
>> >> small and contained enough that we hope this will allow us to share
>> >> ideas and codify a lot of those. Trevor is hoping to begin working on
>> >> this the week of the 2nd September.
>> >>
>> >> 2) We need a templating system in core. Trevor is going to do some
>> >> research on server side templating systems. We hope that the
>> >> templating RFC [1] can get resolved however we are getting to a point
>> >> that we need one as soon as possible and do not want to be blocked by
>> >> the outcome of this RFC, especially given a mustache based templating
>> >> language can address all our current requirements.
>> >>
>> >> [1]
>> >>
>> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
>> >>
>> >> ___
>> >> Wikitech-l mailing list
>> >> Wikitech-l@lists.wikimedia.org
>> >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> >
>> >
>> >
>> > ___
>> > Mobile-l mailing list
>> > mobil...@lists.wikimedia.org
>> > https://lists.wikimedia.org/mailman/listinfo/mobile-l
>> >
>>
>
>
> ___
> Mobile-l mailing list
> mobil...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] dev.wikimedia.org (was Re: build.wikimedia.org)

[Quim Gil]

On Tuesday, August 26, 2014, MZMcBride  wrote:

> Legoktm wrote:
> >This is now at [[dev.wikimedia.org]]? That sounds like a much better
> >name than "build", which I thought was going to be some CI automated
> >builds server from your email title :)
>

dev.wikimedia.org it is, yes. Moving on, please.

We
> already have a publishing platform that we can and should leverage and it
> lives at www.mediawiki.org
>

This is basically decided as well. However, we still need the best of our
technical knowledge to solve this problem: how to extract API documentation
from source code repositories and import it to wiki pages. Your ideas and
help are welcome -- see the ongoing discussion at
http://fab.wmflabs.org/T491


-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] The future of skins

[Trevor Parscal]

Someone in the meeting also claimed that Swig and Twig were compatible, and
that does appear to be generally true, but I think there are some
deviations.

- Trevor


On Wed, Aug 27, 2014 at 1:39 PM, Juliusz Gonera 
wrote:

> Someone in one of our meetings mentioned that Twig is a PHP
> implementation of Mustache. This doesn't seem to be the case though.
> We need a templating solution that works both on the server and the
> client.
>
> On Tue, Aug 26, 2014 at 5:21 PM, Trevor Parscal 
> wrote:
> > Thanks for summarizing the meeting Jon.
> >
> > So, let's get Twig/Swig into core then, eh? :)
> >
> > - Trevor
> >
> >
> > On Tue, Aug 26, 2014 at 3:53 PM, Jon Robson 
> wrote:
> >>
> >> Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and
> >> talked about the future of skins. Hopefully this mail summarises what
> >> we talked about and what we agreed on. Feel free to add anything, or
> >> ask any questions in the likely event that I've misinterpreted
> >> something we talked about or this is unclear :)
> >>
> >> Specifically we talked about how we are unhappy with how difficult it
> >> currently is for developers to create a skin. The skin class involves
> >> too many functions and does more than a skin should do e.g. manage
> >> classes on the body, worry about script tags and style tags.
> >>
> >> Trevor is going to create a base set of widgets, for example a list
> >> generator to generate things like a list of links to user tools. The
> >> widgets will be agnostic to how they are rendered - some may use
> >> templates, some may not.
> >>
> >> We identified the new skin system will have two long term goals:
> >> 1) We would like to get to the point where a new skin can be built by
> >> simply copying and pasting a master template and writing a new css
> >> file.
> >> 2) Should be possible for us in future to re-render an entire page via
> >> JavaScript and using the modern history push state re-render any page
> >> via the API. (Whether we'd want to do this is another consideration
> >> but we would like to have an architecture that is powerful enough to
> >> support such a thing)
> >>
> >> As next steps we agreed to do the following:
> >>
> >> 1) Trevor is going to build a watch star widget on client and server.
> >> We identified that the existing watch star code is poorly written and
> >> has resulted in MobileFrontend rewriting it. We decided to target this
> >> as it is a simple enough example that it doesn't need a template. It's
> >> small and contained enough that we hope this will allow us to share
> >> ideas and codify a lot of those. Trevor is hoping to begin working on
> >> this the week of the 2nd September.
> >>
> >> 2) We need a templating system in core. Trevor is going to do some
> >> research on server side templating systems. We hope that the
> >> templating RFC [1] can get resolved however we are getting to a point
> >> that we need one as soon as possible and do not want to be blocked by
> >> the outcome of this RFC, especially given a mustache based templating
> >> language can address all our current requirements.
> >>
> >> [1]
> >>
> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
> >>
> >> ___
> >> Wikitech-l mailing list
> >> Wikitech-l@lists.wikimedia.org
> >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> >
> >
> > ___
> > Mobile-l mailing list
> > mobil...@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/mobile-l
> >
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you

[Bartosz Dziewoński]

On Sat, 09 Aug 2014 03:41:01 +0200, Bartosz Dziewoński  
 wrote:


James HK has now submitted a patch to implement Composer support in the  
Vector skin [1] – somebody more familiar with Composer than me should  
probably review and merge it, and document how one can actually use this  
to install the skin.


[1] https://gerrit.wikimedia.org/r/#/c/152927/


It has been merged now.

Somebody more familiar with Composer than me should probably update skin  
installation instructions in various places with a mention of the  
possibility of using Composer. :)


--
Matma Rex

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] The future of skins

[Juliusz Gonera]

Someone in one of our meetings mentioned that Twig is a PHP
implementation of Mustache. This doesn't seem to be the case though.
We need a templating solution that works both on the server and the
client.

On Tue, Aug 26, 2014 at 5:21 PM, Trevor Parscal  wrote:
> Thanks for summarizing the meeting Jon.
>
> So, let's get Twig/Swig into core then, eh? :)
>
> - Trevor
>
>
> On Tue, Aug 26, 2014 at 3:53 PM, Jon Robson  wrote:
>>
>> Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and
>> talked about the future of skins. Hopefully this mail summarises what
>> we talked about and what we agreed on. Feel free to add anything, or
>> ask any questions in the likely event that I've misinterpreted
>> something we talked about or this is unclear :)
>>
>> Specifically we talked about how we are unhappy with how difficult it
>> currently is for developers to create a skin. The skin class involves
>> too many functions and does more than a skin should do e.g. manage
>> classes on the body, worry about script tags and style tags.
>>
>> Trevor is going to create a base set of widgets, for example a list
>> generator to generate things like a list of links to user tools. The
>> widgets will be agnostic to how they are rendered - some may use
>> templates, some may not.
>>
>> We identified the new skin system will have two long term goals:
>> 1) We would like to get to the point where a new skin can be built by
>> simply copying and pasting a master template and writing a new css
>> file.
>> 2) Should be possible for us in future to re-render an entire page via
>> JavaScript and using the modern history push state re-render any page
>> via the API. (Whether we'd want to do this is another consideration
>> but we would like to have an architecture that is powerful enough to
>> support such a thing)
>>
>> As next steps we agreed to do the following:
>>
>> 1) Trevor is going to build a watch star widget on client and server.
>> We identified that the existing watch star code is poorly written and
>> has resulted in MobileFrontend rewriting it. We decided to target this
>> as it is a simple enough example that it doesn't need a template. It's
>> small and contained enough that we hope this will allow us to share
>> ideas and codify a lot of those. Trevor is hoping to begin working on
>> this the week of the 2nd September.
>>
>> 2) We need a templating system in core. Trevor is going to do some
>> research on server side templating systems. We hope that the
>> templating RFC [1] can get resolved however we are getting to a point
>> that we need one as soon as possible and do not want to be blocked by
>> the outcome of this RFC, especially given a mustache based templating
>> language can address all our current requirements.
>>
>> [1]
>> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
> ___
> Mobile-l mailing list
> mobil...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] Standardising icons across projects

[Yuvi Panda]

Just to note - it is only the iOS app that uses the font. The android
one has always just used SVGs.

-- 
Yuvi Panda T
http://yuvi.in/blog

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Simplest UI for creating & editing Phabricator tasks

[Andre Klapper]

Every new tool has its learning curve, and feedback helps to investigate
making it less steep, so thanks for the feedback! :)

On Wed, 2014-08-27 at 10:54 +0300, Amir E. Aharoni wrote:
> == Four ==
> Another thought: I searched for the attachment icon. I found it, but I am
> not sure that it would be easy to find for all users. I might be
> subjective, thought, because I upload a lot of screenshots and mileage may
> vary for other users.

Anecdotal comment: Enough users don't find the "Add an attachment"
button/link in Bugzilla tickets either (and either ask how to add a
screenshot, or upload to a 3rd party website and paste the link) so I'm
not too afraid that things can get much worse...

andre
-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Standardising icons across projects

[Jon Robson]

Since we had the luxury of having several people in the office,
Trevor, Juliusz, Rob Moen, Ed Sanders, Shahyar, May, Monte and I sat
down to talk about the problem we currently have of having no standard
way to create icons. Here is my write up of this meeting, again, if
you attended please add/correct me on anything and if you were not
please ask for clarification where needed.

Currently we have two modes of creating icons in MediaWiki
1) Using a font
2) Using SVGs with PNG fallbacks
and the markup varies depending on what extension you look at.

We discussed both approaches and advantages and disadvantages of each.
One of the major disadvantages of the WikiFont is the additional HTTP
request it creates to download the font and cannot be embedded in the
stylesheet using data uris like SVGs can (due to URL size
restrictions).

One of the major advantages of WikiFont is you can design a grayscale
icon, and style it using font colour. Shahyar was happy to move Flow
to using SVG based fonts if we could build grayscale SVGs and change
their colours using ResourceLoader. One concrete example is when you
have an icon used in a constructive anchor. The icon needs to be
green, but when hovered over a lighter green.

Another advantage brought up by May was that currently she finds it
much easier to build icons in this way, and that having to maintain
separate coloured versions of the SVGs is a pain point to her.

We decided that we should push towards using SVGs that can be built
into fonts for the purpose of the app.

As next steps
1)  Monte to explore using SVGs in the Wikipedia apps. He will create
font from SVGs. He will work with May to ensure her workflow is as
easy as before.

2) Trevor is going to look into how we can automatically generate
different colour versions of SVGs and automatically create PNGs from
them.

3) I am going to aim to agree on a standard icon HTML markup for
mediawiki ui. We still have an issue with the fact that everyone is
using different HTML markup to create icons. After reviewing all our
current approaches [1] it was clear that we were relatively closely
aligned and that it simply is a case of agreeing on class names.

We aim to get all the above done by Sept 15th, 2014 so please poke us
on the mailing list if you haven't had a follow up then.

Full disorganised notes can be found here [2].

[1] https://www.mediawiki.org/wiki/Icon_standardisation
[2] http://etherpad.wikimedia.org/p/Icon_standardisation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OAuth and callbacks

[Merlijn van Deen]

On 27 August 2014 20:13, Chris Steipp  wrote:

> * Assuming we implement one or two of: dynamic callbacks, automatic
> approval of apps, or public consumers, but not all three, which are
> most desired?
>

I would order them:
 1. Public consumers. As I understand it, there's no way to work around
this, other than having your program connect to your own endpoint which
then connects to WMF servers.
 2. Dynamic callbacks. These can be worked around (setting a cookie, for
instance), but most libraries assume they can set/need to set the callback.
Implementing this means more OAuth libs will work with less work.

Automatic approval - as long as approval is reasonably fast, I don't see
why this is important. Testing can be done with the author's account, even
if the consumer has not been approved yet. Maybe that needs to be mentioned
more clearly -- it's possible people are not aware of it.

Merlijn
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] OAuth and callbacks

[Chris Steipp]

For those who run one of our 76(!) approved OAuth apps, or are using
OAuth extension on their own wiki..

We have a patch [1] from Mitar to allow OAuth apps to pass a
configurable callback during the OAuth handshake. This will probably
make a lot of app author's lives easier, but can also open up a couple
avenues of abuse-- specifically, it's needed for covert redirect
attacks [2]. If OAuth app authors chose loose callback requirements,
which we can assume will happen if we make approvals automatic (bug
65750), and we ever allow public consumers (huggle was asking for that
for a long time), then it would be possible for attackers to abuse our
OAuth setup.

So far, I've been really conservative about how we use OAuth (there
are two other features we would have to enable to make this attack
likely). I'd like to hear other's thoughts about:

* Assuming we implement one or two of: dynamic callbacks, automatic
approval of apps, or public consumers, but not all three, which are
most desired?

* If we do implement all three, we can limit how the callback can
differ from what is registered. I put some suggestions on the gerrit
patch, but would that cause more confusion than help?


[1] - https://gerrit.wikimedia.org/r/153983
[2] - http://tetraph.com/covert_redirect/oauth2_openid_covert_redirect.html

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Simplest UI for creating & editing Phabricator tasks

[Amir E. Aharoni]

Thanks for the replies.

> > Another thought: I searched for the attachment icon. I found it, but I
am
> > not sure that it would be easy to find for all users. I might be
> > subjective, thought, because I upload a lot of screenshots and mileage
may
> > vary for other users.
>
>
> Maybe you and me are getting old?  ;) Note that, strictly speaking, users
> are not "attaching" (clip metaphore) but uploading a file that can be used
> anywhere and linking it to the description / comment, all at once. The
> tooltip says "Upload File" and you see an "up" arrow in a cloud. This is
in
> fact a character from Awesome Font, so if you find a better alternative at
> https://fortawesome.github.io/Font-Awesome/icons/ we can propose it
> upstream.

Sorry for being unclear.

I meant not so much the appearance of the icon, but the fact that it is so
small and that it appears on a toolbar with quite a lot of other small
icons. If a user knows that such an icon is supposed to be there, it's
possible that the user will find it, but a new user may need a separate
explanation.


--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬


2014-08-27 19:19 GMT+03:00 Quim Gil :

> Hi,
>
> On Wednesday, August 27, 2014, Amir E. Aharoni <
> amir.ahar...@mail.huji.ac.il>
> wrote:
>
> > Thoughts along the way:
> >
> > == One ==
> >
> > > http://fab.wmflabs.org/maniphest/task/create/ (imagine that the
> "Points"
> > field is not there).
> >
> > What if I don't have this link?
> >
>
> We still have to define the content of the homepage, so there. More about
> the content of the soon-to-become homepage at http://fab.wmflabs.org/T12
>
> See also https://www.mediawiki.org/wiki/Phabricator/Help#Creating_a_task
>
>
> I tried click the + at the top of the screen. This gave me a menu that
> says:
> > Create New:
> > Maniphest Task
> > Pholio Mock
> > Paste
> >
>
> Now it says
>
> Create New:
> Task
> Mockup
> Paste
>
>
> > (Come to think of it, I guess that Paste is kinda like Pastebin,
> > but that's because I'm a developer.)
> >
>
> Also like Copy&Paste, a term most users landing in that page will be
> familiar with. But anyway, if you clicked that button because you wanted to
> create a task, "Create New: Task" is a clear choice now.
>
>
> > *However*, since it is so similar to email, it's all the more confusing
> > when you get to the details. In email, the usual order of fields is
>
>
> But this is not an email interface. It is a task creation interface. If you
> want to create a task, "Title" is a clear concept, "CC" is probably clear
> as well (and if not, leaving it empty is just fine), the fact that tasks
> are classified into "Projects" is a familiar concept too (and if not, you
> can also leave it blank), and "Description" doesn't need any explanation.
>
>
>
> > you must
> > take into account that lots of people don't bother reading field labels
> and
> > get very confused.
> >
>
> Only Title and Description accept free text, so getting it wrong is
> actually somewhat difficult. :) I think this is quite of a low barrier for
> any English speaking user of MediaWiki of Wikimedia sites. Even the
> "English speaking" part can be improved in the future (but I'm digressing
> here).
>
>
> == Three ==
> > I tried typing "MediaWiki" in projects and got an auto-completion with an
> > umbrella icon. "Why umbrella?", I thought. And then I got it :)
> >
>
> Good!  :)
>
> The list of projects we have currently in fab.wmflabs.org is quite random
> (i.e. you were lucky to find a "MediaWiki" project, created just for
> testing purposes long time ago). By Day 1 we will have a full list of real
> projects, type-ahead should offer sensible results, and icons of projects
> will follow a consistent guideline.
>
>
> > == Four ==
> > Another thought: I searched for the attachment icon. I found it, but I am
> > not sure that it would be easy to find for all users. I might be
> > subjective, thought, because I upload a lot of screenshots and mileage
> may
> > vary for other users.
> >
>
> Maybe you and me are getting old?  ;) Note that, strictly speaking, users
> are not "attaching" (clip metaphore) but uploading a file that can be used
> anywhere and linking it to the description / comment, all at once. The
> tooltip says "Upload File" and you see an "up" arrow in a cloud. This is in
> fact a character from Awesome Font, so if you find a better alternative at
> https://fortawesome.github.io/Font-Awesome/icons/ we can propose it
> upstream.
>
>
> --
> Quim Gil
> Engineering Community Manager @ Wikimedia Foundation
> http://www.mediawiki.org/wiki/User:Qgil
> ___
> 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/

Re: [Wikitech-l] Simplest UI for creating & editing Phabricator tasks

[Quim Gil]

Hi,

On Wednesday, August 27, 2014, Amir E. Aharoni 
wrote:

> Thoughts along the way:
>
> == One ==
>
> > http://fab.wmflabs.org/maniphest/task/create/ (imagine that the "Points"
> field is not there).
>
> What if I don't have this link?
>

We still have to define the content of the homepage, so there. More about
the content of the soon-to-become homepage at http://fab.wmflabs.org/T12

See also https://www.mediawiki.org/wiki/Phabricator/Help#Creating_a_task


I tried click the + at the top of the screen. This gave me a menu that says:
> Create New:
> Maniphest Task
> Pholio Mock
> Paste
>

Now it says

Create New:
Task
Mockup
Paste


> (Come to think of it, I guess that Paste is kinda like Pastebin,
> but that's because I'm a developer.)
>

Also like Copy&Paste, a term most users landing in that page will be
familiar with. But anyway, if you clicked that button because you wanted to
create a task, "Create New: Task" is a clear choice now.


> *However*, since it is so similar to email, it's all the more confusing
> when you get to the details. In email, the usual order of fields is


But this is not an email interface. It is a task creation interface. If you
want to create a task, "Title" is a clear concept, "CC" is probably clear
as well (and if not, leaving it empty is just fine), the fact that tasks
are classified into "Projects" is a familiar concept too (and if not, you
can also leave it blank), and "Description" doesn't need any explanation.



> you must
> take into account that lots of people don't bother reading field labels and
> get very confused.
>

Only Title and Description accept free text, so getting it wrong is
actually somewhat difficult. :) I think this is quite of a low barrier for
any English speaking user of MediaWiki of Wikimedia sites. Even the
"English speaking" part can be improved in the future (but I'm digressing
here).


== Three ==
> I tried typing "MediaWiki" in projects and got an auto-completion with an
> umbrella icon. "Why umbrella?", I thought. And then I got it :)
>

Good!  :)

The list of projects we have currently in fab.wmflabs.org is quite random
(i.e. you were lucky to find a "MediaWiki" project, created just for
testing purposes long time ago). By Day 1 we will have a full list of real
projects, type-ahead should offer sensible results, and icons of projects
will follow a consistent guideline.


> == Four ==
> Another thought: I searched for the attachment icon. I found it, but I am
> not sure that it would be easy to find for all users. I might be
> subjective, thought, because I upload a lot of screenshots and mileage may
> vary for other users.
>

Maybe you and me are getting old?  ;) Note that, strictly speaking, users
are not "attaching" (clip metaphore) but uploading a file that can be used
anywhere and linking it to the description / comment, all at once. The
tooltip says "Upload File" and you see an "up" arrow in a cloud. This is in
fact a character from Awesome Font, so if you find a better alternative at
https://fortawesome.github.io/Font-Awesome/icons/ we can propose it
upstream.


-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Simplest UI for creating & editing Phabricator tasks

[Quim Gil]

On Wednesday, August 27, 2014, rupert THURNER 
wrote:

> is there a way to simply order tasks so one can retrieve a list? top of
> list then gets fixed first?
>

There are workboards for projects, which are a bit more complex/flexible
than this. See for instance the workboard of the Wikimedia Phabricator Day
1 project:

http://fab.wmflabs.org/project/board/31/

Is this what you are looking for? You can also create lists of tasks
through search queries i.e. open tasks assigned to qgil sorted by priority:
http://fab.wmflabs.org/maniphest/query/j.RJXIy2lbry/#R

You can try more searches at
http://fab.wmflabs.org/maniphest/query/advanced/

PS: Amir, I'll reply to your email later today. Thank you for the quick and
complete response!


-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Simplest UI for creating & editing Phabricator tasks

[rupert THURNER]

is there a way to simply order tasks so one can retrieve a list? top of
list then gets fixed first?

rupert
 Am 27.08.2014 09:18 schrieb "Quim Gil" :

> Hi,
>
> Users of the future Wikimedia Phabricator will have a very simple and
> straightforward interface to create and edit tasks. Bugzilla's UI was one
> of the top complaints from new/casual users, and we can fix this in
> Phabricator easily. Currently we are testing this setup in fab.wmflabs.org
> ,
> where you can see an example:
>
> http://fab.wmflabs.org/maniphest/task/create/ (imagine that the "Points"
> field is not there).
>
> Advanced users needing to prioritize tasks, assign them to someone, and
> resolve them can join the Triagers team in order to get the additional
> permissions:
>
> http://fab.wmflabs.org/project/view/74/
>
> We are still fine tuning this process at http://fab.wmflabs.org/T64 --
> your
> feedback is welcome.
>
>
> --
> Quim Gil
> Engineering Community Manager @ Wikimedia Foundation
> http://www.mediawiki.org/wiki/User:Qgil
> ___
> 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] Simplest UI for creating & editing Phabricator tasks

[Amir E. Aharoni]

Thoughts along the way:

== One ==

> http://fab.wmflabs.org/maniphest/task/create/ (imagine that the "Points"
field is not there).

What if I don't have this link?

I tried click the + at the top of the screen. This gave me a menu that says:
Create New:
Maniphest Task
Pholio Mock
Paste

As some people already complained, I don't know what Maniphest, Pholio and
Paste are. (Come to think of it, I guess that Paste is kinda like Pastebin,
but that's because I'm a developer.)

I quite like the big "Report a Bug" button on the main screen of Bugzilla,
although I'd be the first to admit that the screen that appears after click
it is pretty awful.

== Two ==
The Create New Task screen.

First thought: It looks a lot like web-based email around 2003! :)

The above is not a bad thing. Email composition is fairly simple and common
and the design is OK.

*However*, since it is so similar to email, it's all the more confusing
when you get to the details. In email, the usual order of fields is To, Cc,
Subject, Body. The order here is Title (subject), CC (there's no "To"),
Projects (What am I supposed to write there?), Points (OK, you asked to
ignore that), Description (Body).

I can get used to it, but if it's for more general public, then you must
take into account that lots of people don't bother reading field labels and
get very confused.

== Three ==
I tried typing "MediaWiki" in projects and got an auto-completion with an
umbrella icon. "Why umbrella?", I thought. And then I got it :)

== Four ==
Another thought: I searched for the attachment icon. I found it, but I am
not sure that it would be easy to find for all users. I might be
subjective, thought, because I upload a lot of screenshots and mileage may
vary for other users.


--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬


2014-08-27 10:18 GMT+03:00 Quim Gil :

> Hi,
>
> Users of the future Wikimedia Phabricator will have a very simple and
> straightforward interface to create and edit tasks. Bugzilla's UI was one
> of the top complaints from new/casual users, and we can fix this in
> Phabricator easily. Currently we are testing this setup in fab.wmflabs.org
> ,
> where you can see an example:
>
> http://fab.wmflabs.org/maniphest/task/create/ (imagine that the "Points"
> field is not there).
>
> Advanced users needing to prioritize tasks, assign them to someone, and
> resolve them can join the Triagers team in order to get the additional
> permissions:
>
> http://fab.wmflabs.org/project/view/74/
>
> We are still fine tuning this process at http://fab.wmflabs.org/T64 --
> your
> feedback is welcome.
>
>
> --
> Quim Gil
> Engineering Community Manager @ Wikimedia Foundation
> http://www.mediawiki.org/wiki/User:Qgil
> ___
> 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

[Wikitech-l] Simplest UI for creating & editing Phabricator tasks

[Quim Gil]

Hi,

Users of the future Wikimedia Phabricator will have a very simple and
straightforward interface to create and edit tasks. Bugzilla's UI was one
of the top complaints from new/casual users, and we can fix this in
Phabricator easily. Currently we are testing this setup in fab.wmflabs.org,
where you can see an example:

http://fab.wmflabs.org/maniphest/task/create/ (imagine that the "Points"
field is not there).

Advanced users needing to prioritize tasks, assign them to someone, and
resolve them can join the Triagers team in order to get the additional
permissions:

http://fab.wmflabs.org/project/view/74/

We are still fine tuning this process at http://fab.wmflabs.org/T64 -- your
feedback is welcome.


-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The future of skins

[Antoine Musso]

Le 27/08/2014 08:59, Niklas Laxström a écrit :
> 2014-08-27 1:53 GMT+03:00 Jon Robson :
>> 2) We need a templating system in core. Trevor is going to do some
>> research on server side templating systems. We hope that the
>> templating RFC [1] can get resolved however we are getting to a point
>> that we need one as soon as possible and do not want to be blocked by
>> the outcome of this RFC, especially given a mustache based templating
>> language can address all our current requirements.
>>
>> [1] 
>> https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
> 
> At this point about everyone needs templating library as soon as
> possible and do not want to get blocked by the RFC. Please, let's all
> work together to complete the RFC for the benefit of everyone.
> 
>   -Niklas

Hello,

I am backing up Niklas on this point.  The future of skins depends on a
HTML templating system which, once agreed and implemented, will land in
the mediawiki/core platform.  From there future of skin can build on top
of it.

As I understand Jon summary, the idea is a proof of concept based on
Mustache that would be out of mediawiki/core.  Any experience acquired
in that experiment would help move forward the HTML templating library
RFC in one way (twig) or an other (mustache).


-- 
Antoine "hashar" Musso


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l