Lets discuss the categorization on the other thread and keep this for icon design.
On Tue, Aug 6, 2013 at 10:50 PM, Kasun Indrasiri <[email protected]> wrote: > Yeah, we will come up with a better classification. > > > On Tue, Aug 6, 2013 at 1:51 PM, Samisa Abeysinghe <[email protected]> wrote: > >> On categorizing, that needs to come as a design decision from ESB and >> mediation experts collectively. >> >> We (tooling team) were looking at this yesterday, and what we have right >> now is only an alphabetical ordering. That is useful only for some cases. >> But even on the classification on the ESB UI is not right, as what we >> understood when we looked at them yesterday. For e.g "Advanced" category >> seemed to be the place where most useful yet complex mediators are located, >> and "advanced" has no meaning. >> >> >> >> On Tue, Aug 6, 2013 at 1:37 PM, Srinath Perera <[email protected]> wrote: >> >>> Hi Jonathan, >>> >>> Often these flows are understood by look at them as a one unit holistic >>> manner, not by moving mouse to each one. So getting the icons to respond to >>> the mouse might not work. >>> >>> I think we need to either figure out clear icons or put a word that make >>> it clear what each icon does. >>> >>> --Srinath >>> >>> >>> On Tue, Aug 6, 2013 at 11:18 AM, Nuwan Bandara <[email protected]> wrote: >>> >>>> >>>> >>>> >>>> On Tue, Aug 6, 2013 at 6:57 AM, Jonathan Marsh <[email protected]>wrote: >>>> >>>>> My initial impression was that it would be very difficult to >>>>> comprehend and distinguish such a breadth of icons if they are all the >>>>> same >>>>> shape and color scheme, and differ only in the interior graphics which are >>>>> pretty tiny in all cases. >>>>> >>>>> >>>>> >>>>> So +1 to a limited number of categories to help classify different >>>>> basic types, and representing them in different colors and/or shapes. >>>>> >>>> >>>> +1, we need to categorize, also why do we stick to square type icons >>>> and try to put everything into that ? Why not have icons with different >>>> shapes (of cause meaningful shapes), like funnels, pipes etc, so >>>> collectively it will make much more scene. >>>> >>>> >>>>> >>>>> >>>>> Also, for the complexity of these icons, why are we trying to squeeze >>>>> them into such a tiny space? Can you really tell at a glance what each of >>>>> these steps and the whole sequence are trying to accomplish? >>>>> >>>>> >>>>> >>>>> There are some other very cool ways we could push this to the next >>>>> level, for instance place the icons on a isometric 3d (ala sim-city) type >>>>> grid, or have the flows represented by arcs instead of simple linear >>>>> arrows, or adding steps causes an animated restructuring of the flow >>>>> similar to what you see in https://code.google.com/p/gource/, or >>>>> having icons grow as you hover over them like the mac launcher bar… >>>>> >>>> >>>> +1, on hover zooming the icon is a standard practice, we can even stick >>>> a tool tip on hover, which will add more context. >>>> >>>> Regards, >>>> /Nuwan >>>> >>>> >>>>> >>>>> >>>>> -Jonathan >>>>> >>>>> >>>>> >>>>> *From:* [email protected] [mailto: >>>>> [email protected]] *On Behalf Of *Srinath Perera >>>>> *Sent:* Monday, August 05, 2013 3:37 AM >>>>> *To:* architecture >>>>> *Subject:* Re: [Architecture] Developer-Studio Icons >>>>> >>>>> >>>>> >>>>> I prefer Concept 4, basically to draw the idea in EIP icon style >>>>> (simple lines, but too detail picture). >>>>> >>>>> >>>>> >>>>> Kasun, Chanaka and myself was chatting. I think we need to group icons >>>>> by type (e.g. filters, conditions, transform, do external call ). We can >>>>> use the same grouping we have in palettes, and then all icons have same >>>>> look and feel. >>>>> >>>>> >>>>> >>>>> Some thoughts on concepts >>>>> >>>>> >>>>> >>>>> Log, BAM - stethoscope >>>>> >>>>> Aggregation, Clone, Iterate - EIP aggregator Icon, EIP splitter Icon, >>>>> EIP splitter Icon, >>>>> >>>>> Event - EIP pub/sub icon >>>>> >>>>> Drop, router - EIP routing diagram >>>>> >>>>> Filter - funnel >>>>> >>>>> Header, Property >>>>> >>>>> OAuth, Entitlement >>>>> >>>>> XSLT, PayloadFactory, Smook >>>>> >>>>> Class, Command - "{java}" >>>>> >>>>> Call, Callout - EIP request, replay Icon >>>>> >>>>> router - EIP Icon >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Thanks & Regards, >>>> >>>> Nuwan Bandara >>>> Technical Lead; **WSO2 Inc. * >>>> *lean . enterprise . middleware | http://wso2.com * >>>> *blog : http://nuwanbando.com; email: [email protected]; phone: +94 11 >>>> 763 9629 >>>> * >>>> <http://www.nuwanbando.com/> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> ============================ >>> Srinath Perera, Ph.D. >>> http://people.apache.org/~hemapani/ >>> http://srinathsview.blogspot.com/ >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> Thanks, >> Samisa... >> >> Samisa Abeysinghe >> VP Engineering >> WSO2 Inc. >> http://wso2.com >> http://wso2.org >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Kasun Indrasiri > Software Architect > WSO2, Inc.; http://wso2.com > lean.enterprise.middleware > > cell: +94 71 536 4128 > Blog : http://kasunpanorama.blogspot.com/ > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks, Samisa... Samisa Abeysinghe VP Engineering WSO2 Inc. http://wso2.com http://wso2.org
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
