Before working on Kwippe I had no idea how many interesting graphics you could find in old dingbat fonts! Many of them were thrown online in the 90s, and tracking down the licenses and authors isn’t always easy. We’ve relied on Font Squirrel and DaFont for a few of these gems, and included references to their license page about them. It seems people created this stuff from books they scanned, personal drawings, and other miscellaneous sources that seem a bit nebulous. But some of these images are amazing - Davy’s Dingbats is one of my personal favorites. The art itself doesn’t always translate perfectly to SVG, I’ve found that once converted to layered SVGs, some of the files contain way too many path definitions to be useable. I had to get rid of some otherwise cool robots because they turned out a bit fuzzy around the edges, and others have such strange layering that our system can’t make good sense of them.

But for anybody interested in fonts - take a look at the dingbat fonts - there is way more variety than you’ve imagined!

One thing we’ve paid extra careful attention to in developing our art database is licensing and copyright. This is in part because our co-founder is a lawyer! But also, we realize that for Kwippe to be the awesome tool that we’re hoping it will be, it has to build artwork that people can actually USE. And how you can use an image is highly dependant on the type of licensing the author has used.

We’ll have a complete guide to the licenses in our help section, but today I added a feature that I already love, which is color sorting by license type. For now I’ve divided our artwork into 3 basic categories:

• Public Domain (yay!)
• Open Source (great!)
• Creative Commons (careful!)

Our Creative Commons category has some incredible art that we’re really grateful to have - but you do have to be careful when using it. The Noun Project uses this designation for most of their artwork. The gist of CC artwork is that you must attribute the author in some fashion. For websites, apps, and even books this is really easy to do - just throw up a link in your credits section. But for printing, CC art can be tricky. How do you use CC art for a t-shirt, for example? We actually had to Google that one recently… and it seems there is no exemption for printed materials. They still expect you to put an attribution on your item, no matter how small. And don’t even think about using a CC image as part of a LOGO or something like that. For logo morphing you’re much better off with a Public Domain (PD) image. Luckily we’ve got a pretty nice selection of those for folks to use as a base for logos and more.

The Open Source stuff is licensed under generous licenses like MIT and Apache, where the goal of licensing is really just so that you can’t go back and sue the author for any reason. But this artwork is free to use without attribution, which makes it different from CC. However, you still probably shouldn’t use an Open Source image as a logo unless you morph it beyond recognition - (this is NOT a legal opinion, just my own interpretation!). We will be posting links to every single license file on our designer page - so you’ll be able to read the exact license of that piece of art.

Another important thing we’ve done is make sure not to include ANY art with a “non commercial” or “no derivatives” license. These just don’t work for our system (which makes derivatives!) - or for our customers - who should be able to use everything in our app for commercial products, as well as non commercial.

I’m still working on a nice sorting system so people can sort by license, of even eliminate showing art of the wrong license type. We hope this proves helpful for all - and also keeps people mindful that you need to pay attention to licenses and give authors credit whenever using licensed work.

Visit our Flickr page here - we’ve posted thousands of free emojis and icons.

Well as we’ve started posting to social media as a bit of a necessary evil, I have to say I’m a bit aghast at how difficult this is, compared to the past. Sure, it’s a lot easier to post to a myriad of social networks, but each post is like throwing something into the abyss. We just don’t have the large social network the most people marketing online have - we haven’t been marketing anything in years, as we’ve been busy raising a family - without the time and energy to focus on a Pinterest or Twitter following!

So for somebody starting fresh, getting traction on social media is no easy thing. I probably did the wrong thing by converting my Monster Coding twitter account to a Kwippe account - but heck I do have nearly 700 followers there, versus - well, uh, NONE…

Then I’ve used a cool tool called Social Pilot to post to Pinterest - which seems cool, but since I haven’t actually spent time on Pinterest, following others, pinning, etc - my pins pretty much go into the abyss.

Then there is Flickr - the one service that I’ve been so happy with that I decided to pay for it!

While we haven’t done the whole “follow a thousand people so they follow you back” yet - what I do have on Flickr is an awesome stream of data about our images. Since my images are subject and color grouped - this is an amazing source of data for us! We can see what images are getting play, and what images aren’t. This will help us to shape a better Kwippe. We’ll use the topics hot on Flickr to flesh out cool art packs, and the popular colors to shape better color palettes for people.

So THANKS Flickr! We appreciate the tool - a spot of brightness in our social media world!

One thing I knew when developing Kwippe was that our art had to pull up blazingly fast, or users would click off. Also, search results needed to be returned in a near instantaneous fashion, with as relevant of artwork as possible. In additon, we needed to develop related keyords and categories for thousands upon thousands of images. All of this had to be done by just 1 person: me.

Scary.

Ah and I forgot to add that this needed to be done on a total shoe-string budget (as in, for the less than the price of a good pair of running shoes each month). So I began researching different platforms for deliver search results to an app - as well as pricing plans for databases, rest api services, and any other services that claimed to help serve up your data in some kind of automagical, lightening fast format.

I quickly saw that Firebase - my authentication provider and first stab at database and storage - could become hideously expensive, very quickly. $1 per G of data? Aside from being 10 times the going rate, it’s a bad omen for the speed your data will be served if you begin really gathering steam with tons of simultaneous users. And nobody works this hard to launch the world’s next greatest app in order to grow slowly! While I still like Firebase for authentication and basic user info, I knew it wouldn’t work to serve up my data - in addition to the fact that there’s be no way for that to work offline or in a mobile app.

So after trying out 4 or 5 other database/rest api services - I began wondering if maybe I couldn’t come up with something better - a system where users could access ONLY the data they needed, through the smallest chunks of data possible, delivered as fast as possible. As I began reading about binary versus text based data, and how much more efficient and fast it is to serve binary files to users - I realiized that my dream database may in fact, be no database at all.

What! You must be crazy! An app with tens of thousands - and eventually hundreds of thousands - of images and keywords - run with no database at all? Yup. That’s what I’m telling you. File system only, baby. And here’s how I did it.

First - I ditched the idea that just because I need JSON, meant that I had to store the data as JSON. I looked at everything: Protocol Buffers, FlatBuffers, MessagePack, and a couple of others. But frankly the documentation for that most of stuff in Javascript was pretty terrible, and the main thing I took away from researching all of this was that BINARY was key. Put your stuff into Binary and you’re way better off. Ok. I chose CBOR for my binary format, just because it was super easy to deal with, documentation was excellent, and I could easily encode that data into CBOR via Node.js, then decode it client side, no problema. But that was just the first step to database-free bliss.

The 2nd piece was something I didn’t read about in any of the above resources - and shrunk my binary file sizes by more than 50% - in some cases much more. I used an awesome, uber simple string compression library, to compress the strings before encoding to CBOR. I even convert arrays to strings before saving.

Then it was just a matter of developing a rational system for placing my art files, as well as keyword files, into folders, and creating an index file for each folder - and I was ready to serve up both images and pre-cached keyword searches, all from the file system. And an added benefit - is that all of the artwork files, search terms, and indexes - get cached by your browser - so that unless I update the files, the user doesn’t have to request that data again. This kind of codeless cache management it certainly bliss to this programmer, as managing all of that programatically it just 1 more headache I don’t need.

Now you may be asking “ok but how the heck do you generate all this crap!” Simple, with Node.js. With 2 database systems on my end: the gorgeous and magical RethinkDB on my local machine, as well as good ole Node Dirty for temporary operations. So RethinkDB houses all of our stuff - and is used to regenerate our keyword and related keyword definitions, which do have to be re-done whenever you add artwork. I realize that isn’t the best system - but there isn’t really any way around that if you want to use a database free system.

That part could easily be done each night by chron job.

As for getting related keywords for the images - I developed a few scripts in Node.js to query word api services that return beautiful lists of synonyms, antonyms, and even categories for each term entered. I then match that up with terms that actually exist in our DB, so the user isn’t offered a word that we don’t actually have artwork for.

While I don’t want to give away all of my secret sauce here - I can say that the art, keywords and related keywords are loading faster than I ever imagined, and I like to think that users will notice the difference.

One area our family has been highly impacted by is autism, as our adorable 4 year old, Catherine, “experiences” this condition. I guess that’s the politically correct way to say it! She is still preverbal, and we are working hard with her to develop communication, in all forms. One thing we’ve worked a little with it PECS cards, although I have to say the cards were a bit cumbersome for us to use as a primary communication system, and sign language has gone a little better. She likes the cards when we can find a card for what she actually wants at the time she wants it (and we have it! No use for a “grapes” card when we’ve just run out!) - but I’ve been on a little bit of a quest to find some BETTER art, to make custom cards. Here are some hand signals I used to create an art pack - although the Mulberry symbols I talk about below have a lot more variety, including nouns and verbs from everyday life. I’m also working in getting the ASL alphabet into our app, so that people can create colorful variations to incorporate into their materials. I’d love to find a large open source or Creative Commons collection, with even more hand signals.

I found a fantastic [Creative Commons collection from the UK] (https://github.com/straight-street/mulberry-symbols) - it looks the funding dried up and they had to discontinue development, which is too bad - but I am delighted that the graphics have been released to the public. We’ve got nearly 3,000 of these image in Kwippe. I am working on ways to add words, backgrounds, and more to make these graphics more accessible to parents, children, and therapists - and would love any advice on what people would like to see.

Welcome to Kwippe! We’re hard at working adding the finishing touches to our app, and have started posting on social media so that a few people will come visit our app when we go live! We’ve added some icon packs to an Etsy store. I don’t really have high hopes that we’ll sell much on the highly saturated Etsy, but I wanted someplace to showcase some of what Kwippe can build for you. And that’s just a start - I only used open source well known icon packs for those, we have a lot of fantastic artwork from places like OpenClipArt.org and others that really shines when you begin working with it in Kwippe.

Thanks for visiting, and hope you’ll check us out in early August when we go live!