Evolution of Gramener Design Toolset

At Gramener, we have been con­tinu­ously evolving our Design pro­cess over the past years. These im­prove­ments have been to stay in tune with the emer­ging trends in design, ad­opt in­dustry stand­ard tools and cre­ate a cus­tom Design frame­work that helps us de­liv­er out­stand­ing visu­al­iz­a­tions.

This post cov­ers the ‘tools’ as­pect of the design im­prove­ments we’ve im­ple­men­ted, and it dis­cusses the chal­lenges faced and con­sid­er­a­tions on com­ing up with a per­tin­ent tool­set to cater to Gramener’s core of­fer­ing of Information Design & Data Visualization.

Earlier Process brief and tool­set used:

Until a year back, the primary tool we used dur­ing the design phase was paper-pencil for cre­ation of Design con­cepts, while the ac­tu­al designs were cre­ated on Powerpoint. For most en­gage­ments we had a low-fidelity design as de­liv­er­able, where­in the pa­per sketches were trans­lated to a ba­sic rep­res­ent­a­tion on MS Powerpoint us­ing snipped im­ages of charts and oth­er ba­sic dash­board com­pon­ents.


In cer­tain en­gage­ments, when there was a need to show a closer-to-actual rep­res­ent­a­tion, a high-fidelity design was cre­ated, again on Powerpoint us­ing im­por­ted SVG ob­jects or drawn chart ele­ments. There was al­most no pro­to­typ­ing or demon­stra­tion of in­ter­activ­ity, save the oc­ca­sion­al power­point slide trans­itions. The need for an in­tern­al Design lib­rary was met by hav­ing all designs stored on the Gramener file server and ex­posed on a search­able, min­im­al­ist­ic UI, that was spruced up with ba­sic pre­views and meta-tags.


Given the abil­ity of Gramex, Gramener’s plat­form to quickly pull out charts from the engine’s lib­rary and setup a ba­sic, work­ing ver­sion of visu­al dash­boards, his­tor­ic­ally, there was not much of a need for a stand­ard­ized design tool. Hence, Powerpoint was a quick and light al­tern­at­ive that fit in well with the skill­set of Data Consultants, which is a role com­prised of func­tion­al ana­lysts, who had in­nate com­fort with MS Office rather than the Adobe suite of products.

Evolving needs:

With the evol­u­tion of pro­jects done by Gramener and the rap­id scale-up in cli­en­tele and team size, the need was felt for a re­think of the above men­tioned stack. With a large num­ber of first-time visu­al­iz­a­tion ad­op­ters among­st cli­ents, we sensed their com­fort in re­view­ing solu­tions with a high-fidelity design that showed visu­al design as­pects as close to the fi­nal solu­tion as pos­sible.

With in­creas­ing func­tion­al com­plex­ity and data size of our visu­al solu­tions, Data Consultants had to spend more time in the solu­tion con­cep­tu­al­iz­a­tion and data ana­lys­is phases, where­as there was an in­creased need for ad­di­tion­al sup­port dur­ing the Design phase.

Challenges faced:

In sum­mary, the key chal­lenges faced with the above simplist­ic pro­cess & tool­set were:

  • Variation in qual­ity, fin­esse and look-and-feel of designs cre­ated on Powerpoint
  • Long cycle time for design cre­ation, with an of­ten cum­ber­some pro­cess for put­ting to­geth­er the oc­ca­sion­al high-fidelity ver­sions
  • Teething chal­lenges in de­vel­op­ment han­dover & trans­la­tion of the design
  • Need for mul­tiple design re­views dur­ing de­vel­op­ment phase, coupled with re­work
  • Difficulty in demon­strat­ing state trans­itions, in­ter­activ­ity and user flow with­in a visu­al ap­plic­a­tion con­cept

Alternate Solution:

Given these chal­lenges and the ad­di­tion­al con­sid­er­a­tions of scalab­il­ity & rap­id rep­lic­ab­il­ity, we went about eval­u­at­ing changes needed in the pro­cess, tool­sets & frame­work. We spoke to the design com­munity and took first-hand ad­vice from ex­perts in these areas. From the tools per­spect­ive, we eval­u­ated a vari­ety of visu­al design and pro­to­typ­ing tools in­clud­ing Adobe Photoshop, Illustrator, Balsamiq, Axure and Pinegrow, among­st oth­ers. Based on con­sid­er­a­tions of fit­ment to our visu­al­iz­a­tion li­fe­cycle, avail­ab­il­ity of com­ple­ment­ary skill­sets at Gramener and abil­ity to ad­dress the chal­lenges out­lined, we zer­oed in on the fol­low­ing:

Sketchapp – for Visual Design:

The vec­tor graph­ics ed­it­or from Bohemian Coding has been rap­idly gain­ing pop­ular­ity and has quickly built its own com­munity of loy­al users. With ad­di­tion of new role of Information Designer at Gramener, this tool helped us in the fol­low­ing ways:

  • We found that the tool was very easy to pickup due to its in­tu­it­ive us­ab­il­ity, per­haps closer to Powerpoint. It also had ample tu­tori­als and a ro­bust sup­port eco­sys­tem
  • By design, the tool was meant to cre­ate vec­tor ob­jects and nat­ur­ally fit in bet­ter for dash­boards and web ap­plic­a­tions, while oth­er tools were heav­ily skewed to­wards graph­ic design
  • Has a thriv­ing eco­sys­tem of plu­gins for pro­ductiv­ity im­prove­ment, and im­port­antly provides for easy ex­port of style sheets to aid de­vel­op­ment trans­la­tion
  • Comes at a re­l­at­ively eco­nom­ic price com­pared to pop­ular op­tions, Apple hard­ware prices not­with­stand­ing


Invision – for Workflow, Prototyping and Design lib­rary:

A lead­ing pro­to­typ­ing, col­lab­or­a­tion and work­flow plat­form used by sev­er­al design houses around the world, this tool checked-off mul­tiple items in our re­quire­ments list:

  • Provides an end-to-end design work­flow solu­tion with use­ful ad­min fea­tures
  • Has nat­ive in­teg­ra­tion with Sketch and hence it auto­mat­ic­ally syncs, im­ports and stores as­sets from Sketch files. Automatically cre­ates style sheets & en­ables dir­ect look-up
  • Supports ba­sic pro­to­typ­ing needs to show in­ter­activ­ity and trans­itions
  • Has use­ful col­lab­or­a­tion & com­ment­ing fea­tures, and in­teg­rates live design present­a­tion and re­view cap­ab­il­ity
  • Doubles up as a re­pos­it­ory with ver­sion­ing & hence can be used as a design lib­rary


In Summary, be­low is the over­all pro­cess that we have ar­rived at, which has been work­ing well for us and has ad­dressed most of the above-mentioned is­sues we faced:


Method In Madness

Trump’s very pres­ence is chaos, but a visu­al­iz­a­tion of un­struc­tured data such as the Presidential de­bates sure does help identi­fy the ‘Method in Madness’. An Ivy League pro­fess­or look­ing at Gramener’s visu­al­iz­a­tion of the 2nd Presidential de­bate said, ‘A re­mark­able way to break down and fol­low what of­ten seems chaot­ic and ran­dom.’


At the CNN de­bate, with every fin­ger poin­ted at him for the sex-tape con­tro­ver­sy, Trump tried his be­st to de­vi­ate at­ten­tion us­ing his fa­vor­ite fear mon­ger­ing top­ic – ‘ISIS’. There were at least 19 in­stances where Trump men­tioned ‘ISIS’ while Hillary had men­tioned the same only 5 times or so. For more in­sights do play around with our visu­al­iz­a­tion of the de­bate.

The Las Vegas de­bate on October 20th is do-or-die for Trump. Can Trump do any­thing at all to bring life to his dead cam­paign? Irrespective of the out­come, there’s go­ing to be chaos at the de­bate – lots of it.

“Though this be madness, yet there is method in’t.”

– William Shakespeare, Hamlet

Languages that cities love

We built a small tool that helps us re­cruit. It peri­od­ic­ally pulls data off of Github for de­velopers in India, and shows how they are con­nec­ted. You can watch this 2-minute video to un­der­stand how it works.


This data also helps us un­der­stand how pop­ular dif­fer­ent pro­gram­ming lan­guages are across cit­ies. For ex­ample, if we take the top cit­ies, based on the num­ber of users (we’ve been fuzzy about the geo­graphy and in­cluded Colombo and Singapore in­to the mix)…


… and the top pro­gram­ming lan­guages, again based on the num­ber of users …


… it begs the ques­tion: is the pop­ular­ity of lan­guages the same across cit­ies? Or are there cer­tain cit­ies that love or hate cer­tain lan­guages?

This is the dis­tri­bu­tion of pro­gram­mers across these cit­ies:


This does not read­ily lead to any in­sights. But we could look at this num­ber dif­fer­ently. If all cit­ies had the same dis­tri­bu­tion, then what would these num­bers have looked like? In oth­er words, how many de­velopers of each pro­gram­ming lan­guage would each city have had? That’s shown be­low:


So, for ex­ample, Bangalore ac­tu­ally has 321 Javascript de­velopers. But if it had the same per­cent­age of Javascript de­velopers as oth­er cit­ies, it would just have had 263 Javascript de­velopers. So clearly, there are more Javascripters in Bangalore than you’d ex­pect.

The num­bers be­low show the dif­fer­ence between the ex­pec­ted and ac­tu­al num­ber of pro­gram­mers.differences

A few things stand out:

  • If you’re look­ing for Javascript pro­gram­mers, Bangalore and Mumbai would be the two places to vis­it. There are con­sid­er­ably more Javascript pro­gram­mers here than you’d ex­pect.
  • On the oth­er hand, if you’re look­ing for Java pro­gram­mers, you’d be much bet­ter off vis­it­ing Delhi, fol­lowed by Chennai and Bangalore.
  • There’s only one city to vis­it for Python pro­gram­mers – Bangalore. The rest are scattered across the minor cit­ies. (A closer look at the data re­veals that a reas­on­able num­ber are in Kerala.)
  • Colombo, on the oth­er hand, looks primar­ily like a Ruby shop. The fo­cus seems to be server-side de­vel­op­ment. Javascript pro­gram­mers are much rarer than nor­mal.
  • Gurgaon is the primary PHP hub. The city is under-represented in most pop­ular pro­gram­ming lan­guages, but has a thriv­ing group of PHP pro­gram­mers (a lan­guage that Chennai, Bangalore and Mumbai seem to act­ively dis­like.)
  • The biggest hub for iOS de­velopers (Objective-C) is Singapore. Within India, only Pune seems to have a slightly lar­ger than usu­al num­ber of iOS de­velopers – but that’s a mea­gre 20 pro­gram­mers.

Whether you’re a start-up look­ing for your lead de­velopers, or an IT firm re­cruit­ing open source geeks, or just a geek your­self look­ing for friends to hack with, we hope this gives you a idea of which city to vis­it next.