Thanks for sharing this, Ori!
It's a great example of how 'responsive digital design layouts' can be used to provide a better experience on a page, using HTML5.
Over time, I hope we can integrate more of these techniques on Wikipedia, as users will come to expect them once they gain wider adoption.
To that end, we would like to include an example of this mixed media approach in the multimedia vision piece we are preparing together this fall.
Here are a couple more examples, for your viewing pleasure:
* ESPN'S Dock Ellis piece -- one of the first applications of parallax to editorial:
http://sports.espn.go.com/espn/eticket/story?page=Dock-Ellis
* National Geographic's Forest Giant - an experiment with Adobe:
http://blogs.adobe.com/webplatform/2013/05/06/adobe-explores-the-future-of-…
* Stevan Živadinović's Hobo Lobo of Hamelin - an entire parallax children's story:
http://hobolobo.net/
* Nike's nutty scroll behaviors:
http://www.nike.com/jumpman23/aj2012/
These examples come from my son Adam, who is starting to integrate some of these ideas on Triple Canopy. He says there are lots of libraries for these techniques now, mostly just used for marketing sites.
Hope we can bring some of them to Wikipedia too, maybe starting with some of our future multimedia experiments, like article 'covers'.
-f
On Oct 16, 2013, at 5:01 AM, design-request(a)lists.wikimedia.org wrote:
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 15 Oct 2013 15:43:51 -0400
> From: Matthew Flaschen <mflaschen(a)wikimedia.org>
> To: design(a)lists.wikimedia.org
> Subject: Re: [Design] "The Russia Left Behind" (NYT piece)
> Message-ID: <525D9AF7.9060603(a)wikimedia.org>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 10/15/2013 02:31 PM, Quiddity wrote:
>> "Snow Fall - The Avalanche at Tunnel Creek" is the canonical NYT
>> example.
>> http://www.nytimes.com/projects/2012/snow-fall/#/?part=tunnel-creek
>> It was talked about a LOT. https://www.google.com/search?q=snow+fall+nyt
>> a "six-month sixteen-person multimedia project", "immersive story",
>> "spectacle".
>>
>> I'm not sure if there's a particular name for the UI style(?), but
>> someone replicated the dynamic-scrolling aspects in an hour, and then
>> NYT's lawyers descended: https://medium.com/meta/503b9c22080b
>
> Well, it sounds like the issue was that they copied the specific images
> and video at first too, *not* just the general style (transition as you
> scroll, etc.).
>
> Then, they removed the images and video, but I think the Times lawyers
> either didn't get it, or just decided to play hardball.
>
> Matt Flaschen
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 15 Oct 2013 12:52:13 -0700
> From: Steven Walling <swalling(a)wikimedia.org>
> To: "A list for the design team." <design(a)lists.wikimedia.org>
> Subject: Re: [Design] "The Russia Left Behind" (NYT piece)
> Message-ID:
> <CAMryOMVGDdVPPfvFcFqnC_5nWDhg7UGRGL=g3TxZxATO_J=5Ww(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Tue, Oct 15, 2013 at 12:43 PM, Matthew Flaschen
> <mflaschen(a)wikimedia.org>wrote:
>
>> Well, it sounds like the issue was that they copied the specific images
>> and video at first too, *not* just the general style (transition as you
>> scroll, etc.).
>>
>> Then, they removed the images and video, but I think the Times lawyers
>> either didn't get it, or just decided to play hardball.
>>
>
> Yes. Parallax scrolling and effects like Bootstrap's affix.js are most
> certainly not copyrighted by the NYT.
>
>
> --
> Steven Walling,
> Product Manager
> https://wikimediafoundation.org/
>
Wanted to share this, since it made me wow out loud:
http://www.nytimes.com/newsgraphics/2013/10/13/russia/
I'm not referring to the substance of the piece but to its
presentation, which is an impressive composite of a lot of very recent
browser capabilities.
On Thu, Oct 3, 2013 at 11:43 PM, May Tee-Galloway
<mgalloway(a)wikimedia.org>wrote:
> https://www.mediawiki.org/wiki/Flow_Portal/Design/Iteration_5
>
This is great work!, but now the Agora controls specification is
out-of-date while remaining a lot more detailed. Iteration 5 for Flow uses
different colors, and e.g. Flow's plain white [ Reply ] button has
different height and margin than the Agora spec's equivalent [ Other
Actions] button. May Tee confirmed this. I reluctantly agree with her that
updating the Agora controls spec in tandem with these rapid Flow iterations
would be a ton of work, so
https://www.mediawiki.org/wiki/File:Agora_specs.pdf now warns it's out of
date.
Engineers should maintain a split in the Flow CSS between discussion CSS
and "mediawiki.ui override CSS", but the lack of clarity over what's a Flow
design and what's core Agora means the Flow extension is almost guaranteed
*NOT* to deliver a new consistent UI for MediaWiki.
I'll be adding more screenshots to
https://www.mediawiki.org/wiki/Category:Inconsistent_buttons :-(
teamlove,
>
She's mighty Mayte
-- Prince's "House of Brick" version of "Brick House"
--
=S Page Features engineer
Hey all,
Using my volunteer account and time, I have proposed
https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Sidebar_update
The sidebar has long driven many of us who care about usability crazy. I've
proposed what I think is a reasonable compromise, where we don't remove a
lot of links, but create a special new "Contribute" section focused on ways
to participate, and we reword or move major functions like About, Help,
Contact etc.
Comments welcome, naturally.
--
Steven Walling,
Product Manager
https://wikimediafoundation.org/
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
>>
>>
>
