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': '
http://upload.wikimedia.org/wikipedia/commons/4/32/check-icon.svg'
/* 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 <[email protected]> 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 <[email protected] (mailto:
> [email protected])> wrote:
> >
> > > On Sep 19, 2012, at 2:57 AM, "Helder ." <[email protected](mailto:
> [email protected])> wrote:
> > >
> > > > On Tue, Sep 18, 2012 at 9:28 PM, Jon Robson <[email protected](mailto:
> [email protected])> 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 <[email protected](mailto:
> [email protected])> 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
> > > [email protected] (mailto:[email protected])
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > >
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > [email protected] (mailto:[email protected])
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> >
>
>
> _______________________________________________
> Wikitech-l mailing list
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
