There is a product waiting to come out in this space, but it is going to be a difficult chicken egg problem to solve.

Where is the space?

Finding and listening to Carnatic Music is a bad experience today. It can definitely be better. I’ve talked to my fellow carnatic musicians (See research section below) at length about this, and I’ve confirmed that this is a problem everyone has. Inevitably, everyone ends up talking to me for an hour about their problems and how things could be better.

No Spotify? Grooveshark?

Is there something like a spotify or grooveshark for Carnatic Music? No. Sangeethapriya and Youtube do a good job, but finding a good rendition of a krithi (song) or raga (mood) in our mind is a long ordeal. Ideally, I should be able to search through all krithis by name, artist, composer, etc. Sangeethapriya is making advances in this direction, but is quite technically convoluted to hope for much progress in the near future. For a non profit, with technical people working in their spare horus, it is doing a good job.

Why won’t Soundcloud work?

Plainly because the ecosystem is very different. Here’s the thing: Carnatic music today is mostly renditions of existing krithis. There are thousands of krithis composed by saints and musical maestros that are rendered with minor variations. Maybe in a year, we’ll have 5 new compositions.

Can’t we tweak Soundcloud for Carnatic Music?

Maybe, but it’s a long shot. There are a couple of strong reasons I can think of. The standard meta tags of Artists, Album and Track aren’t sufficient. Here’s a more realistic list in order of preference:

  • Krithi name
  • Artist
  • Raga
  • Composer
  • Tala
  • Main diety
  • Type of Song (Varnam/Krithi/Padam/Javali/Devarnama/Thillana)
  • Manodharma
  • Accompanists

What I found from my research:

I talked to about 20 carnatic music performers over a phone call. Each call lasted about an hour, because they had so much to say to me. I took a google-form survey about the features, sent emails to about 150 people, and talked to everyone I know. Then I made a prototype on a Saturday, stealing all the music from Sangeethapriya. It helped people understand what I’m talking about. You can check it out here: http://sangeethapriya-search.herokuapp.com.

Here are a few excerpts from the conversations that would give you an idea of what I’m talking about:

I have to click through ten different pages to preview/download a krithi on Sangeethapriya.

I pay Rs.500 for a couple of CDs every month. I can easily pay Rs.1000 a month for this.

If you can get the lyrics and the track together, that would be great! I’d pay for that.

If I could just filter by raga and krithi name, and then hit play, that would be awesome!

I am a big fan of Y person. If I can get a list of songs by Y, that’ll be all.

Customer Segments:

From my research, I see three customer segments:

Casual Listeners: (Mostly Parents) They value ability to filter by diety/occassion

Active Listeners: (Mostly Students) They value basic filters, lyrics/meaning, notation

Performers: (Intermediate, Advanced and professionals) They value the filters, lyrics and manodharma

Why is this difficult to solve?

Well, all that was said above, is the “Good to have” part of the problem. The real problem is the other side of the spectrum: Content Providers.

And for Carnatic Music, this is really just one big player: The All India Radio, owned by the government of India. Most licenses for Carnatic music for about 10 decades in India, are owned by the AIR, and that’s why this is a hard nut to crack.

Here are the slides I used to showcase this idea to my friends at nilenso at our product pitch day.

Do you think we can build this product?

Do write to me. Or comment using disqus below. Thanks!

‘Tito’ is like Quicksilver inside GIMP. You bring up tito and enter something, it gives a dropdown of possible actions. You hit enter to execute that action. Michael Natterer (maintainer) told me on IRC about a year ago that it can go upstream with a few changes. Quite sadly, I haven’t had the time to make those changes.

It works pretty well though. Here are a few screenshots:

snap apply canvas blur desktop More screenshots here.

Currently implemented features

  • It searches first through labels and then tooltips of actions
  • It supports fuzzy search
  • It is adaptive: frequently used actions appear higher in the results list
  • It shows the tooltip, icon and shortcut in each search result if present
  • It is highly configurable via a preferences window

More high level details in the tito-readme. There is also an old screencast I made. It isn’t great, but you can see it in action ;)

The story behind it

We were four developers who knew little about gtk and git. We started off well and shared our initial prototype. We got a mix of positive and dismissive responses from the gimp dev list. You can see the thread where the devs and I debated the values it provided.

Quite a few devs tried it out and gave me feedback. I incorporated that feedback and fixed bugs and regularly interacted with the team on how it could be better. But tito got a fair amount of push back from the interaction design perspective.

We can finish this together

I really need some company in finishing this up. Mitch (Michael Natterer on IRC) took a look at the diff and suggested a few changes that would make it eligible to go upstream. I’ve created issues for these on github. My gut feeling is that this should take lesser than a week. Please get in touch if you are interested. Let’s collaborate!

TL;DR: Don’t nest CSS. Nest class names instead. This is one of the most useful take-aways from SMACSS. Follow this, and it will change the way you write scss for the better.

With the coming of sass, we have all seen how writing css has gotten easier. We love writing css that is similar to our html. The following would seem natural to us:

HTML for a component
1
2
3
4
5
6
7
8
9
<div class="my-component">
  <header></header>
  <div class="some-section">
    <header></header>
    <p class="description">
      <span class="important"></span>
    </p>
  </div>
</div>
Styling the component (the wrong way)
1
2
3
4
5
6
7
8
9
div.my-component {
  header {}
  .some-section {
    header {}
    p {
      .important {}
    }
  }
}

This gives us the comfort of nesting css the same way we nest html. It gives us context that some-section rests inside my-component, but nothing more. And, this gets convoluted quickly. if I had to override the style for this component elsewhere, I’d have to do something like:

Overriding the style for .important
1
.my-component .some-section p .important {}

The correct way:

Add the context, name of component/module in the class attribute:

HTML for a component
1
2
3
4
5
6
7
8
9
<div class="my-component">
  <header class="my-component-header"></header>
  <div class="my-component-section">
    <header class="my-component-section-header"></header>
    <p class="my-component-section-description">
      <span class="my-component-section-important"></span>
    </p>
  </div>
</div>
Styling the component (the correct way)
1
2
3
4
5
6
.my-component {}
.my-component-header {}
.my-component-section {}
.my-component-section-header {}
.my-component-section-description {}
.my-component-section-important {}

What does this give us?

  • All the context that we got in nesting css. Except that the nesting is in the name instead of nested braces that are hard to read.
  • CSS with minimum specificity so that it is easy to override. For the purpose of subclassing modules, it is preferable to nest the styling by exactly one level. See exceptions below.
  • Independence from structure, so we can move our components around without having to move css around. For this purpose, it is also good to stay away from element selectors.
  • Control over cascading, that you thought was only possible with nesting. The nesting in class names gives a unique name to your selector that is quite hard to override accidentally with cascading.
  • The answer to “Where is the CSS for this?”. Since the selectors have almost a one to one mapping with the class attributes, you just have to file-search for them now.
  • Speed. See how this helped github speed up their diff pages.

Conclusion:

Don’t nest CSS. You could start off with the inception rule, but I strongly suggest you stick to zero nesting levels (see exceptions below).

Exceptions:

  • When you are writing modules that you will subclass, it is necessary to nest (by one level) the styling under the module’s selector so that you can keep the defaults and override only the differences.
  • When overriding base rules, one usually has to provide enough specificity to override an element selector, say. In these cases, nesting (by one level) is ok.

© Srihari Sriraman - 2013