2014-06-13 11:03 GMT+02:00 Ecaterina Moraru (Valica) <[email protected]>:

> Hi,
>
> So we need to replace all our icons calls with variables. This goes in the
> direction of Icon Themes where we can easily replace the icons with
> whatever we want. Not sure how hard is to do this since there are some
> difference between using font sets and normal image sets (img src,
> background-image calls will be replaced by CSS classes that uses the
> font-image). There are a lot of places in our platform/application where we
> will need to make these changes.
>
> I've added all your suggestions on this page
> http://design.xwiki.org/xwiki/bin/view/Proposal/AppBarIcons
>
> A. Glyphicons is nice since is by default provided by Bootstrap. The
> problem is that it contains a limited number of icons. The current
> implementation of Flamingo is using Glyphicons icons.
>
> B. FontAwesome is really nice since it's on github and provides full access
> to the icons. Also it is updated and has a decent community. FontAwesome is
> already used on the design wiki and also there is a macro done by Sergiu.
>
> C. Building our own set from free icon packs is also an interesting
> alternative. The problem is that someone would need to maintain the XWiki
> custom pack. This solution is good when you want to limit the number of
> icons you provide, but we as a platform we want to offer a generous offer
> so we might opt to integrate a more complex set. Still this solution can be
> used by application developers that don't find a suitable icon in the
> provide sets.
>
> So Glyphicons is already integrated in Flamingo and can be used. We could
> also vote to integrate FontAwesome to expand our icons poll. I've made an
> example of icons replacement for the current AppBar view.
> http://design.xwiki.org/xwiki/bin/view/Proposal/AppBarIcons#HReplacements
>

To me it's noticeable, that when used in 16x16px, FontAwesome monochromic
icons are not striking at all.
I also tried them for some menu I did, and it's nice looking, but difficult
to find quickly what they represent.
When comparing to silk as in your table, well, I tend to prefer silk :) But
maybe that can be improved by using differerent colors - but it improves
only some of them (like, rss feed orange, + sign green, etc).
But in greater size (like you show for AppBar), this problem disappears.


>
> Thanks,
> Caty
>
>
>
>
>
> On Tue, Apr 29, 2014 at 10:41 PM, [email protected] <[email protected]>
> wrote:
>
> >
> >
> >
> >
> > On 29 Apr 2014 at 14:08:01, Andreas Hahn ([email protected](mailto:
> > [email protected])) wrote:
> >
> > > FWIW - there is another option of creating your own 'xwiki' icon set.
> > >
> > > We have been using http://fontcustom.com/ with the noun project
> > > http://thenounproject.com/ for almost unlimited icon options.
> >
> > That looks interesting, thanks for pointing this out!
> >
> > -Vincent
> >
> > > regards
> > > Andreas
> > >
> > >
> > >
> > >
> > > Am 28.04.2014 08:46, schrieb [email protected]:
> > > > BTW here are some potentially interesting icon packs with lots of
> > icons:
> > > > http://www.flaticon.com/packs/
> > > >
> > > > Thanks
> > > > -Vincent
> > > >
> > > > On 24 Apr 2014 at 22:15:59, [email protected] ([email protected])
> > wrote:
> > > >
> > > > Yes using font-based icons is interesting (BTW
> > http://fortawesome.github.io/Font-Awesome/icons/ looks richer than
> > http://www.entypo.com/ to me).
> > > >
> > > > However, first we need to decide if we wish to support several icon
> > sets or only have one that can potentially be configured.
> > > >
> > > > Supporting several icon sets means means introducing a new syntax in
> > XWiki Syntax 2.2. For example:
> > > >
> > > > image:icon::
> > > >
> > > > Examples:
> > > > * image:icon:silk:accept
> > > > * image:icon:fa:home
> > > >
> > > > Now that makes it harder to reference an icon as it means more typing
> > so we could also imagine a configurable mapping (defined in
> > xwiki.properties) as follows:
> > > >
> > > > .icon.mappings = accept = silk:accept
> > > > .icon.mappings = home = fa:home
> > > >
> > > > As a user you’d write:
> > > > image:icon:accept
> > > > image:icon:home
> > > >
> > > > (technically we’d check the number of “:” after “icon”. If 2 then
> it’s
> > a named icon set. If 1 then it’s the default mapping)
> > > >
> > > > This would have the advantage of allowing mixing icon sets easily
> > without being verbose and with this we would even be able to rewire icons
> > without changing page content (for example image:icon:accept could be
> > rewired from the silk icon set to the fa icon set’s fa:check).
> > > >
> > > > Now, we could also decide that we don’t introduce the icon set
> > notation and that we only keep the icon: format and that everything has
> to
> > go through the configurable mapping.
> > > >
> > > > Or we could decide that we only ever want one icon set at a time,
> > define properly all the icon names we wish to have and allow configuring
> > the mapping of these name to a an icon set.
> > > >
> > > > WDYT?
> > > >
> > > > Thanks
> > > > -Vincent
> > > >
> > > > On 24 Apr 2014 at 20:38:04, Sergiu Dumitriu ([email protected])
> wrote:
> > > >
> > > > +1 for a font-based icon set, but before deciding on a specific one,
> we
> > > > should make sure that we have a replacement for all the icons that
> > we're
> > > > currently using. After a very quick look, it doesn't look like the
> > > > entypo font covers enough of our needs. Silk doesn't either, to be
> > fair...
> > > >
> > > > On 04/24/2014 01:03 PM, Yacine Kebir wrote:
> > > >> Hello,
> > > >>
> > > >> i have an idea concerning the icons of base skin colibri or others,
> we
> > > >> should integrate "Entypo" on the skin ans delete all image icons,
> the
> > > >> advantage is :
> > > >> 1- we win the chargement time of pages
> > > >> 2- reduce the number of code lines in the code.
> > > >> 3- we can add, edit , put color and change the sise of this icons
> > > >> 4- the skin of this icons are in flat design and we can put it in
> any
> > form
> > > >> 5- its free for any users
> > > >> for more information http://www.entypo.com/
> > > >> wordpress have just integrate this solution
> > > >>
> > > >> Yacine
> > _______________________________________________
> > devs mailing list
> > [email protected]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to