Maybe I was unclear.
I'm not suggesting we make these icons so much as we make the notification
system use them by name.
As in:
mw.notify( {
// This is bad
'icon': '
/* other options here */
} );
vs.
mw.notify( {
// This is good
'icon': 'check'
/* other options here */
} );
- Trevor
On Wed, Sep 19, 2012 at 11:46 AM, Munaf Assaf <massaf(a)wikimedia.org
(mailto:massaf@wikimedia.org)> wrote:
Already in progress.
http://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Icon_Set
They'll eventually be in the Agora library as sprites.
--
Munaf Assaf
On Wednesday, September 19, 2012 at 11:41 AM, Trevor Parscal wrote:
I'm glad this area is getting a lot of
interest - unfortunately I haven't
been able to keep up on this thread but I wanted to give a suggestion
related to adding icons.
It's reasonable to take an option that provides a URL to an icon image,
but
we should have a common (customizable per skin
and language) set of icons
that can be used by symbolic name, like "success", "failure",
"information", "error", etc.
This helps in a few ways:
- We can make sure they match the skin they are being used in
- We can internationalize them
- We can avoid having multiple icons for the same purpose
- It makes it easier to use the icon feature
- Trevor
On Wed, Sep 19, 2012 at 9:56 AM, Krinkle <krinklemail(a)gmail.com
(mailto:krinklemail@gmail.com) (mailto:
krinklemail(a)gmail.com
(mailto:krinklemail@gmail.com))> wrote:
> On Sep 19, 2012, at 2:57 AM, "Helder ." <helder.wiki(a)gmail.com
(mailto:helder.wiki@gmail.com)(mailto:
helder.wiki(a)gmail.com
(mailto:helder.wiki@gmail.com))> wrote:
>
> > On Tue, Sep 18, 2012 at 9:28 PM, Jon Robson <jdlrobson(a)gmail.com
(mailto:jdlrobson@gmail.com)(mailto:
jdlrobson(a)gmail.com
(mailto:jdlrobson@gmail.com))> wrote:
> >
On Commons it seems to take 5 seconds to disappear which is too
>
long as
>
at
> > this point I'm wondering how to dismiss it.
>
>
> I think the time should depend on the length of the message.
> The watchlist notification in Portuguese has ~46 words,
> and if I didn't know what it was saying, that information would be
>
lost.
> > Maybe it should allow us to see
previous notifications by clicking
>
>
> somewhere.
> >
> > On Tue, Sep 18, 2012 at 9:28 PM, Rob Moen <rmoen(a)wikimedia.org
(mailto:rmoen@wikimedia.org)(mailto:
rmoen(a)wikimedia.org
(mailto:rmoen@wikimedia.org))> wrote:
> >
Not sure if this is a known issue, but the notification is at the
>
top
> >
>
>
> of the document regardless of where you are on the page. Meaning if
I'm
at
> the bottom of a long article, I have to
scroll up to the top to see the
> bubble. Should it not be relative to the scroll position?
> > >
> > > I noticed this by firing off a mw.notify('hi james') in the
console at
the
bottom of a long article. This may have gone unnoticed as it seems
mw.notify is only triggered by UI components at the top of the page.
>
> +1. This is bothering me as well.
>
> Helder
I agree.
Just for the record though, lets not forget what it was just weeks ago:
* Only one message at a time, new one wiped previous one from existence
unconditionally
* No way to close it
* Took up full width
* At the top of the page (still)
* Bumped down the article by the height of the message
So we are making some progress here.
Suggestions I saw so far in this thread:
* Notification queue should follow scroll position (fixed position)
* Add close button (even when they close regardless of click target, as
visual clue)
* Extend base framework for universal layout of messages. We already
have
title/body,
to be extended with icon and buttons.
One potential problem with making them appear mid-page (fixed queue) is
when the
bottom of the page is reached. It should then start a new column to the
left.
Other wise it will continue down the page where it can't be seen due
the
queue
following the scroll position.
Another thing I don't like is how they move up in the queue one after
another.
What I like about Growl and Notification Center is that messages stay
fixed
where
they first appear. And new messages are added to the bottom (or
next
column),
or, when the first position is available again, it will re-use
those
positions again.
That way users don't have to re-focus constantly and follow where which
message
went when dismissing some of them. This gets more important as we
start to
> introduce notifications that do user
interactions (sticky ones, which
> should not
> move but be sticky).
>
> However that brings another problem: Resizing the window. The
spreading of
messages
over multiple columns would have to either be re-build after
resizing
the window.
-- Krinkle
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org)