http://designatwikipedia.tumblr.com/post/62048718932/thoughts-on-humanizing…
"With humanizing articles, we have two objectives:
-Creating awareness about the editors and their interests on Wikipedia.
-Promoting connections within the community using shared interests."
The post shares some ideas and mockups and notes, "While the details are
being refined, comments on the general direction towards contributions
or alternate ideas would be super appreciated."
(By the way, after this email, I'm unsubscribing from the design list as
I prep for my sabbatical - more info at
http://lists.wikimedia.org/pipermail/wikitech-l/2013-August/071542.html
. If you need to talk about Wikimedia technical community stuff or
communication before January, please consult Quim Gil, qgil at wikimedia
dot org, or Guillaume Paumier, gpaumier at wikimedia dot org. Thanks!
Looking forward to coming back in January.)
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
[Please CC me on answers as I'm not subscribed.]
Hi,
I plan to enable a guided bug entry form on Wikimedia Bugzilla for
newbies, to make reporting issues slightly easier. It can be seen on
http://boogs.wmflabs.org/enter_bug.cgi?product=Wikimedia&format=guided
Login: test(a)test.wmflabs
Password: testtest
Is this utterly horrible and unusable, or can I deploy it on
bugzilla.wikimedia.org without making designers scream and ignore me for
the rest of my life? The CSS isn't great (at least it *is* CSS now,
sigh), but I needed to start somewhere.
Thanks in advance,
andre
PS: Quick'n'dirty CSS recommendations are also welcome.
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
Hi Jared,
thanks for the feedback!
> -------- Original Message --------
> Subject: Re: [Design] Bugzilla Guided Bug Entry Form
> Date: Wed, 25 Sep 2013 13:34:57 -0400
> From: Jared Zimmerman <jared.zimmerman(a)wikimedia.org>
> Andre, how much control over this do we have?
The upstream code is pretty low quality, and I won't become a great Perl
hacker over night, so the answer is "It depends". :-/
There are a bunch of things that bugzilla.mozilla.org have which make
the experience for the guided bug entry form way nicer[1], but I have
not succeeded yet in convincing Mozilla devs to upstream their changes
to Bugzilla.
> a few notes:
>
> Step 1 of 3: Find out if your issue has already been reported, Please
> search if your bug or feature request has been already reported by
> entering some search words in this box that have to do with your issue,
> for example upload error or search empty. Then press the Search button.
> The results will appear in the box below.
>
> This is pretty verbose, and feels very repetitive, can we just say:
>
> "Search to see if your issue has already been reported."
> __________ [ Search Issues ]
>
> for the search results can we refactor them a bit
>
> Summary / Product / Component / last updated / Assigned to / [This is my
> issue]
The displayed columns and their order seem to be based on the user's
global preferences on columns displayed in Bugzilla search results, so
for a new user they'd pick up the defaults.
Question is if we want to change the defaults.
> [This is my issue] would prompt the user to add the bug to their watch
> bugs list if they have an account,
Interesting, bugzilla.mozilla.org has this feature already "Follow bug"
button for open tickets next to each search result. I guess that's in
their custom "GuidedBug" extension that they use. Upstream ticket is
https://bugzilla.mozilla.org/show_bug.cgi?id=616490
> or prompt them to create an account otherwise.
You will already need an account to reach this bug entry form.
> Can we have the search step on its own page, e.g. force users to search
> before you can manually add their own? The option to add your own could
> show up after you've done a search.
>
> [ My issue is new ]
>
> I assume there will be other components in the list, only one is showing
> now, why is it duplicated in the box and to the right of the box?
That's only the test instance. The text on the right will show the
component description, like on
https://bugzilla.wikimedia.org/describecomponents.cgi?product=MediaWiki
> Can we swap Summary and Component areas?
Yes! Added to my to-do list.
> Having images is VERY helpful esp. if it is a design issue, Can we add
> an image upload step after summary step, and allow multiple images?
I am fine with adding a "Consider adding a screenshot" explanation for
the time being (L10N Eng also asked for this).
I'm not sure how much work it is to allow adding an attachment directly
in this form; I'll investigate.
I'll leave support for uploading several attachments at once to upstream
developers - https://bugzilla.mozilla.org/show_bug.cgi?id=278469
> is URL usually have helpful information in it, if so perhaps we could
> move that field up below results/expected results
Will do.
> Can we make reproducibility an optional step and just add the control
> under the "steps to reproduce" not in a new section just below the text
> field?
Currently "Reproducibility" is optional and under the "Click here to
show four more optional questions" on
http://boogs.wmflabs.org/enter_bug.cgi?product=MediaWiki&format=guided
> Wrap the remaining questions in a collapsed section called "Advanced",
> Additional notes, browser, OS(?), mediawiki version(?), etc.
To clarify: By remaining you also mean "Results" and "Expectations"?
> Overall this is a great improvement. If you're up for making some
> changes and iterating on it later when the design team or I have some
> free cycles that would be great.
Alright. Again thanks a lot for the very helpful and quick ideas!
andre
[1] see https://bugzilla.mozilla.org/enter_bug.cgi
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
Thanks for this. This is very surprising...
cc'in design and mobile list. Maybe we should rethink using css
sprites for our icons?
On Mon, Sep 23, 2013 at 2:57 PM, Ori Livneh <ori(a)wikimedia.org> wrote:
> http://www.mobify.com/blog/data-uris-are-slow-on-mobile/
>
> ---
> Ori Livneh
> ori(a)wikimedia.org
I uploaded the Agora spec on dropbox[1] to
https://www.mediawiki.org/wiki/File:Agora_specs.pdf . I tried to put in
appropriate disclaimers and links, edit away.
I filed bug 54360 to implement new Agora spec in the mediawiki.ui CSS
module. Now that the LESS CSS preprocessor[2] is in core there's some
interest from various engineers. I work on it and a Special:Agora sample
page after hours, but it's slow going.
[1] https://www.dropbox.com/s/wa9uayq9j09agyh/Agora%20specs.pdf , from
August 20.
[2] http://lesscss.org/
Cheers,
--
=S Page Features engineer
Hello!
I've been working on the MassMessage extension, and am planning on having
it deployed on Wikimedia sites[1]. The extension allows a user to send a
message to a list of users across all projects. It is intended to replace
the current global message delivery[2] system we have. Any design input you
might have would be appreciated.
The special page will only be visible to advanced users and administrators
who are sending messages. I've set up a test wiki where you can play with
it and test it out[3] (it might be a bit slow). You will need to login
(username: 'Admin', password: 'test'). I've also uploaded a few screenshots
to MediaWiki[4].
Thanks,
-- Kunal Mehta (User:Legoktm)
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=52723
[2] https://meta.wikimedia.org/wiki/Global_message_delivery
[3] http://legoktm.instance-proxy.wmflabs.org/wiki/Special:MassMessage
[4] https://www.mediawiki.org/wiki/Extension:MassMessage/Gallery
Resending now that I'm on the design(a)lists.wikimedia.org list.
On Tue, Sep 17, 2013 at 9:55 AM, Adam Baso <abaso(a)wikimedia.org> wrote:
> There's been some additional discussion on this, taking search engine and
> Find in Page optimization into account.
>
> https://bugzilla.wikimedia.org/show_bug.cgi?id=45951
> https://bugzilla.wikimedia.org/show_bug.cgi?id=49202 (my duplicate with
> some Find in Page-oriented stuff)
>
> The smart search engine / Find in Page stuff is moderately complex, so I
> think the tappable options for section expansion are the place to start.
>
> It seems to me that the following achieves TOC-like information at a
> glance while balancing page load performance, usability, user choice, and
> user choice measurement:
>
> * Don't auto-expand articles by default
> * Do have a JavaScript-injected "Expand Sections" / "Collapse Sections"
> feature at the top of articles with multiple sections
> * Do have a user preference for Auto-Expand Sections on Article Load.
> * To gauge love/hate for features, have two preferences as follows
>
> *Show 'Expand/Collapse Sections' Option at Top of Articles*
> On / Off (default = On)
>
> *Auto-Expand Sections on Article Load*
> *Note: this may slow page load time*
> On / Off (default = Off)
>
>
>
>
>
>
>
>
> On Mon, Sep 16, 2013 at 4:20 PM, Jared Zimmerman <
> jared.zimmerman(a)wikimedia.org> wrote:
>
>> I like the idea of expanding by default because it fixes my pet peev of
>> not being able to do a find on page from my mobile browser without first
>> expanding all sections.
>>
>> *
>> *
>> *
>> *
>> *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia
>> Foundation
>> M : +1 415 609 4043 | : @JaredZimmerman<https://twitter.com/JaredZimmerman>
>>
>>
>>
>> On Mon, Sep 16, 2013 at 12:52 PM, Mathieu Stumpf <
>> psychoslave(a)culture-libre.org> wrote:
>>
>>> I didn't followed the thread, but if you try to consult the french
>>> wiktionary with the mobile interface it's impossible: section title are
>>> links so when you try to uncollapse them, you follow the link.
>>>
>>> Le lundi 16 septembre 2013 à 11:05 -0700, Brion Vibber a écrit :
>>>
>>> > On Mon, Sep 16, 2013 at 10:51 AM, Arthur Richards
>>> > <arichards(a)wikimedia.org> wrote:
>>> > If we still want to explore dynamically loading article
>>> > sections (which we all seemed to be in favor of when we did
>>> > annual planning back in June), it's hard for me to imagine how
>>> > we could realistically pull that off if we display sections
>>> > uncollapsed as default.
>>> >
>>> >
>>> > We could rig up an "infinite scroll" type of situation, where we
>>> > basically:
>>> >
>>> >
>>> > * load section 0 and section 1
>>> >
>>> > * leave placeholder <div>s for sections 2 and beyond
>>> >
>>> > * when the user scrolls down into section 1, start loading section 2
>>> > in the background
>>> >
>>> > ** prepare the same thing for the bottom of section 2 load section 3,
>>> > etc...
>>> >
>>> >
>>> > Of course a problem with this setup is that if you go offline partway
>>> > through reading the article, the later sections might be unavailable
>>> > when you scroll down to them.
>>> >
>>> >
>>> >
>>> > -- brion
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Design mailing list
>>> > Design(a)lists.wikimedia.org
>>> > https://lists.wikimedia.org/mailman/listinfo/design
>>>
>>>
>>> _______________________________________________
>>> Design mailing list
>>> Design(a)lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/design
>>>
>>
>>
>> _______________________________________________
>> Mobile-l mailing list
>> Mobile-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>>
>
+ design-l
On 17 Sep 2013 12:47, "Jon Robson" <jdlrobson(a)gmail.com> wrote:
> It's a very easy change to make - one line of code but it seems like the
> majority of people are saying a preference button is a bad idea.
>
> Personally I think it would be more useful use of time to get event
> logging up and running in some form to work out what is the best way of
> dealing with this problem and if it is a problem before coding anything...
> On 17 Sep 2013 12:25, "Juliusz Gonera" <jgonera(a)wikimedia.org> wrote:
>
>> On 09/16/2013 11:28 AM, aude wrote:
>>
>> On Mon, Sep 16, 2013 at 7:34 PM, Jon Robson <jdlrobson(a)gmail.com> wrote:
>>
>>> The more I think about it, the more I think, in its current state
>>> mobile should not collapse sections by default. If you really want to
>>> find a lower section, scrolling down the page and being able to
>>> collapse a section to see the next one is easy, yet if you just want
>>> to read the article in its entirety it is annoying to have to click to
>>> expand a section.
>>>
>>
>> I think default collapsed is good but would be nice to have one place
>> to click to "expand all" sections, instead of one-by-one.
>>
>>
>> I thought about such a button too. It's on my todo, I'll put something
>> together for the experimental mode when I have some time.
>>
>> --
>> Juliusz
>>
>> _______________________________________________
>> Mobile-l mailing list
>> Mobile-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>>
On Mon, Sep 16, 2013 at 10:51 AM, Arthur Richards
<arichards(a)wikimedia.org>wrote:
> If we still want to explore dynamically loading article sections (which we
> all seemed to be in favor of when we did annual planning back in June),
> it's hard for me to imagine how we could realistically pull that off if we
> display sections uncollapsed as default.
>
We could rig up an "infinite scroll" type of situation, where we basically:
* load section 0 and section 1
* leave placeholder <div>s for sections 2 and beyond
* when the user scrolls down into section 1, start loading section 2 in the
background
** prepare the same thing for the bottom of section 2 load section 3, etc...
Of course a problem with this setup is that if you go offline partway
through reading the article, the later sections might be unavailable when
you scroll down to them.
-- brion