CategoryHyperlinks

🔖 Kerala vs Gujarat Models: History Matters (archive)

A historic look at the Gujarat and Kerala development models, separated from political biases. The two models have evolved over the last two centuries, and even have some commonalities.

Gujarat

Known to have a market-friendly, growth first approach that aims to raise incomes that would lead to trickle down.

The trading communities in Gujarat — Parsis, Bohras etc — weren’t evangelical and there were fewer Christians here. Thus, there wasn’t much focus on education or health.

The route to prosperity was through business and commerce, not education.

The freedom movement was strong in Gujarat with many important figures coming from here. The people were politically aware, but it didn’t lead to any significant social reforms.

Presently, the citizens who’ve left the state have set up businesses and developed roots in other places. The remittances contribute to ~1% of the state’s GDP.

Kerala

Known to have a state-led focus on human development parameters like health and education, creating a foundation for economic growth.

Princely states of Travancore and Kochi and the british controlled the region of present day Kerala in the 1800’s. When the Christian missionaries arriived they opened up schools. Seeing this the princely states followed suit and started providing free education. They also focussed on public health and vaccinations.

Travancore introduced private property rights to increase incentive for farming productivity. This led to a budget surplus which was invested in education and health.

Since the royal families were focussed on taking care of their subjects the freedom movement didn’t get a stronghold here. However, there was a focus on social reform for civil rights of the lower castes that was led by the non-varna Hindus.

Presently, even with high HDI scores, citizens leave the state to find opportunities elsewhere, but remittances from them contribute to ~14% of the state’s GDP.

🔖 Building empathy in a product team (archive)

Product teams should always keep their customers in mind so that the changes they make doesn’t affect UX negatively. Ideas about making changes to the product should be based on empathy, not assumptions. Empathy means:

  • Understanding the users perspective
  • Not placing blame, rather understanding the cause of the problem
  • Realizing the emotional impact of the problem

While design researchers can communicate some of this, real empathy is felt by seeing users interact with the product first-hand. This empathy leads to a shared understanding of the problem and a motivation to work towards a common goal.

🔖 ABEM: A more useful adaptation of BEM (archive)

ABEM brings BEM and Atomic Design together by adding some variations to the BEM convention:

  • Prefix blocks with a-, m- or o- to signify its level.
  • Allow block names to be camelCase, changing .o-subscribe-form__field-item to .o-subscribeForm__fieldItem. This makes grouping of the class names easier and our brains can parse the shapes faster.
  • Use selectors that have multiple classes, especially for modifiers.
  • Modifier classes should have a - prefix.

For example:

.m-signUpForm--isOpen { display: block }
/* ... would become... */
.m-signUpForm.-isOpen { display: block }

This makes the HTML easier to read too:

<section class="m-signUpForm m-signUpForm--isOpen"></section>
<!-- ...would become... -->
<section class="m-signUpForm -isOpen"></section>

Applying modifiers like this has its drawbacks since it applies to all child elements too. The article goes into detail on how to resolve this.

🔖 Atomic Design (archive)

Atomic design is a strategy for creating design systems by breaking elements into distinct levels:

  • Atoms are the smallest building blocks, that is HTML elements (like inputs, buttons and headings)
  • Molecules combine atoms together to build something useful (like a form or a card)
  • Organisms combine molecules to create distinct sections of an interface (like the header or the product grid)

These are combined to make the actual designs in the form of:

  • Templates are organisms stitched together to form pages.
  • Pages are specific instances of templates.

This system allows you to design by assembling rather than deconstructing which means you don’t have to cherry pick patterns later.

🔖 BEMIT: Taking the BEM Naming Convention a Step Further (archive)

BEM only tells us about how classes relate to each other. They don’t provide an insight into the global non-relative meaning of the class. This is where namespaces based on ITCSS help.

Namespaces like o- for objects and c- for components should be added as a prefix to the normal BEM classes. Now by looking at class names — like o-card and c-user__photo — we are able to reason about its scope, where else we can use it, and how we can reuse or modify it.

Responsive classes should be added as suffixes with with an @. For example – u-hidden@print or o-layout@md. The @ symbol needs to be escaped in the CSS like so .u-hidden\@print.

🔖 MindBEMding – getting your head ’round BEM syntax (archive)

BEM class names are meant to be descriptive of their place, relationships and states.

.person {}
.person__hand {}
.person--female {}
.person--female__hand {}
.person__hand--left {}

In the above example it is important to note the order of --modifiers and __elements:

  • A person has an element hand with the modifier for which side.
  • A person has a modifier for gender that has the element hand.

Good BEM naming requires us to understand which category something falls into. Just because a something lives inside a block doesn’t always mean that it is an element. It could be a block in its own right. For example, something like a site logo on the header could be .header__logo, but if you are going to reuse the logo in the footer too you could separate it out into its own block .site-logo.

🔖 More Transparent UI Code with Namespace (archive)

CSS code should be transparent and self-documenting. Naming conventions like BEM help us see how components and its elements relate to each other. Namespaces give us a more global sense of the classes, in a non-relative way. Using namespaces gives us:

  • Clarity of what a class does and its scope
  • Confidence to know what changes will have side effects

These are the suggested namespaces:

  • o- for objects that are used a wide variety of contexts
  • c- for components which are a distinct part of the design
  • u- for utilities that are often used along side other classes
  • t- for themes (if your app has them)
  • s- for scopes that contain content coming from elsewhere (like a CMS)
  • is- or has- for states
  • _ for ugly hacks
  • js- for any DOM that has a JavaScript behavior on it
  • qa- for running automated tests or other test engineering requirements

🔖 Font sizing with rem (archive)

Defining font sizes in px gives you control but it prevents the user from increasing the font size on some browsers (till IE9). em is more accessible and allows for resizing, but since the unit is relative to the font size of its parent it has a compounding effect which is hard to manage.

The rem unit is relative only to the root html element’s font size. By setting the html‘s font size to 62.5% you can use rems almost like px, in that 1.4rem would be 14px (because 62.5 × 1.6 = 100, 16px being the usual browser default text size)

🔖 How NeuraCache works (archive)

We remember things better by using spaced repetition and active recall. Spaced repetition involves:

  1. Reviewing once every few days (rather than multiple times in the same day)
  2. Reviewing new information once within 24 hours.
  3. Review material every few weeks or months once its stick initially

When reviewing don’t re-read, try to recall from memory. This locks information in your long term memory.

🔖 Pixel Art Workflow: Stuff that artists should know about but don’t

Planning

Resolution

Take your target resolution and divide by an integer to figure out your pixel art size. The pixel art game canvas should be scaled without anti-aliasing. All UI elements are normally scaled and usually smoothened by anti-aliasing.

Color

Pick a color palette and try to stick with it. If you add a new color go back to old sprites and see if they need to be updated. Avoid retro color palettes since those were often chosen for technical and not aesthetic reasons.

Mocks & Character Sheets

Based on the resolution and colors make a fake screenshot of the game, nothing too complicated, just a general screen. This will help you decide if you’d like to commit to those colors and that resolution. Next, use the mocks as a background and size reference to draw the characters. Draw them side-by-side to get the comparative sizes correct.

Elements

Entities

Start with concept art based on the story. Reduce the concept art into pixel art giving readability importance over details. Decide complexity based on how much the sprite would need to be animated.

Tilesets

Should have lower contrast than entities. Research different methods of using tilesets — manual placing, code that automatically picks and places the right ones.

Background

Don’t add a lot of information to these, the colors should clearly indicate that these objects don’t have collision. Use parallax.

Decals & Props

Objects you can place around in your world. They shouldn’t draw too much attention, but add detail to the world. Should have low contrast and low color count.

Effects & Particles

Use sparingly as they take up a lot of focus. Should follow the same colors and rules and the rest of the art.

Scrivener is a writing tool that brings together your notes and research.

  • Allows composing text in small chunks that can be reordered later
  • Outlining tools for planning and restructuring
  • Create collections of documents in the project based on metadata and completion
  • A corkboard to see and move around sections of your writing, or to look at your research.

❤️ Scrivener

Workflowy is a list that contains infinite lists.

  • Organizes information as a fractal document
  • Each bullet point can be a document of its own that has bullet points inside it ad infinitum
  • Navigate between bullet points and focus on one small part at a time.

❤️ Workflowy

🔖 The Comprehensive 8pt Grid Guide (archive)

The system uses points not pixels because the pixel density of devices wary and we want to keep our designs consistent across different densities. iPhones for example could be rendering 2x or 3x the number of pixels. So, we design for the smallest size, and get perfect rendering by multiplying by 2 or 3.

Typography
Font sizes may stray from multiples of 8 but the line heights shouldn’t so as to maintain vertical rhythm. For example, a font size of 12px is acceptable as long as the line height is 16px.

Icons
Should be constructed in the 8pt grid and exported for higher density screens.

Layout
For the horizontal layout, customize your column grid library or settings to make sure the gutters are a multiple of 8. Setup variables to use later when setting dimensions, margin and padding:

:root {
  --small-space: 8px;
  --medium-space: 16px;
  --large-space: 24px;
  --x-large-space: 32px
  /* and so on */
}

🔖 8-Point Grid

Use multiples of 8 to define dimensions, padding and margins of all elements. Set the root font size to 16px and use 0.5rem increments to build the layout. By limiting your spacing options and font size options you get a more consistent UI and faster coding times.

🔖 Bending the Curves of Productivity (archive)

While working we should also be continuously packaging our work into research, notes, brainstorms, examples, outlines, prototypes, drafts, todos etc. This is helpful for our future selves.

If we see our work as creating these intermediate packets, we can find ways to create value in any span of time, no matter how short. Productivity becomes a game of matching each available block of time with a corresponding packet of value.

By attaching value to small packets of work we are able to do something meaningful even in smaller chunks of time. This adds up in the long run.

🔖 The Procrustean Bed of Productivity (archive)

In a complex environment, yearly, quarterly, and even monthly goals are an exercise in fauxductivity. That doesn’t mean you shouldn’t have goals: you should, but you shouldn’t peg them to our position around the sun. And you definitely shouldn’t plan out week-by-week what you’ll be doing in 2-3 months. Rather, you should have a target (whatever you’re tempted to call a “year goal”), and focus on making the next most important piece of progress on it. 

We try to fit our goals and projects into systems that we’ve created — spreadsheets, todo lists etc. Since real life can be very different from the structure these tools impose, the tools can actually get in our way rather than help. Tools without limitations like paper, or a whiteboard might work better long term.

🔖 The Map Is Not the Territory (archive)

The map of reality is not reality. Even the best maps are imperfect. That’s because they are reductions of what they represent.

Our mind reduces the complexity of reality by abstracting it into models. When our abstraction is to simplistic, and when we apply the models without understanding the situations, the results are problematic.

We must remember that maps aren’t reality and so when working with one we should always have backups for safety and take into consideration margins of error.