(UX) economic behavior — permadata blog #3
By: Romaric Ruga
Tags: Permaculture, Firebase, Ecology, Design, UX

(UX) economic behavior — permadata blog #3

users conscious

sometimes, the simplest aspects of development can raise the most questions. It’s the case with my PlantSearch component

evolving in an environment with limits

I come from an era where you have auto-completion on search input. My friend once told: one day, your search engine will give you what you’ve been looking for even before you press any key

eMergy cost

this fantasy is arriving, but with a tremendous cost. I could mention : API calls & volume, UI re-rendering, personal data storage .. but in fact, it’s just electricity & hardware

Electricity is not that cheap energy you’ve been using increasingly these decades. As for hardware, production logistics & waste management are not solved with sustainable answers

being conscious of the real emergy cost of digital technology is crucial for our century. It may make the difference between a future with or without humans

firebase quotas

another limitation, more pragmatic (but less holistic), is my hosting (Firebase) solution quotas & monetary cost

I already switch the biggest of my database from Firestore to MongoDB to empower query abilities & avoid exponential call number. But, for exemple, external network requests (like querying database) are free up to 100.000 operations

That’s mainly why I want to remove highly call consuming features like :

letter-by-letter queries & auto-completion

every priorities search results (I’ll explain below)

& replace them with :

manual send (enter key press or button click), with at least 3 characters

(enter key press or button click), with at least 3 characters progressive & targeted search, starting with the simpler operations & able to take back at any of them; as seen below

user time & focus

when you speak to people about economic decline, they often answer you : nobody want to go back to the stone age. Militant minimalists would then answer : what can’t you do with a book, a paper & a pen that you can do with a computer ?

the first one doesn’t want to spend too much time & focus on doing what they are aiming to achieve. We have to keep its user experience super-fluid while reducing the amount of gadgets which we provide

the second one absolutely doesn’t want to use screens. We should ask ourselves what crucial features would then justify using digital tools but those we would waste enormous amount of time doing them in real life

these are just feelings about people I’ve met & projections about how they would interact with the permadata project. We could use them to validate feature perimeter

the process

processing

a plant got an unique ID (from its latin taxonomy) & is related to data atoms, like [data:name] (name type data). In my initial use cases, there is three way to match a plant using a search key :

they key equals ID (1 result)

the key is contained in some IDs (* results)

they key is contained in some [data:name]

& this edge-case : they key is exactly matching only one [data:name]

splitting steps

check if there is a document with ID === key

no — next step

yes — accesses the plant page

another option for the “yes” could be to ask confirmation to the user before leaving the page

2. results on searching key in fragment of plant IDs

0 — next step

1 — UI prompts : do you want to access this { plant.name } ? (yeah we need to automatically bind another query for the plant’s first [data:name] , unless Mongo can aggregate it ..)

, unless Mongo can aggregate it ..) 2..*— UI shows a select with different plant options display name

3. results on searching key in fragment of [data:name] value, in the current language

0 — UI displays “no result found”

1 & key exactly matching value — accesses the plant page

1 else — UI : do you want to access this { plant.name } ?

2..* — UI shows a select

engaging user

my goal is to influence users to go for the cheapest interaction by presenting them as the laziest. & I’m also working on a full gamification process

I know that, putting this form on the application will make it consume more. But playing is also one of the best way to develop habits in human behavior

engaging user means giving him the feeling of flowing steps & of participating to his global “score” improvement. Instinctive & proportionally rewarding call progression :

matched unique ID (+++) matched unique by [data:name] (++) list of matched by ID fragment (+) list of matched by [data:name]

accessing a special step, is possible by :

clicking on “next step” from a previous one (example, results from step 3 did not match your search on a name & you want to push it to step 4)

from point 0, if you already know that you won’t match on the first steps. This option has to be more interesting than making the server run through useless calculation

for the second point, we can imagine a switch like :