1/15
I have made a lot of custom #UI components for @SkivvrNoCode. In a #NoCode app #UX is very important, and I am paying a lot of attention to interactions.
What should you remember when building your custom controls? As an example, I would use an input control from Skivvr 🧵⬇️
2/15
TL;DR:
👉 Different input states
👉 Labels, placeholders, and tooltips
👉 Keyboard interactions
👉 Mouse interactions
👉 Smart behaviours
👉 Autocomplete
👉 Tab order
⬇️
3/15
👉 Hover, Active, Disabled states: how the input will look, when the user interacts with it, or when it's disabled. Defining a style for an Active state is especially important to highlight a focused input.
4/15
👉 To be clear about the input content, you should use a label, placeholder, or a tooltip, that describes it. Or sometimes even a combination of those.
Skivvr uses either text labels or icon + tooltip. The tooltip has a slight delay, so it will not appear immediately.
5/15
👉 Keyboard interactions: what should happen if the user presses Escape? Tab? Are there any conflicts with your app's global keybindings? Is the change immediately reflected when you type, or does the user need to press "Enter"?
6/15
In Skivvr, you press Enter to "apply" the value. You can cancel a change you made in input by pressing Escape.
7/15
Numeric inputs support more interactions. For example, pressing the up arrow will add 1 to the value, and the down arrow will subtract 1. Pressing the Shift + up or down arrow will increase or decrease a value by 10. These changes are immediately applied to the element
8/15
Input keybindings should not conflict with global keybindings. For example, in Skivvr, pressing the Delete key will remove the selected element. But if you are editing the value in input, it should not do that.
9/15
👉 Mouse interactions
Think about what should happen if the user clicks outside the input after editing the value. Should the value be applied? Or should clicking outside undo an edit?
10/15
Do you need any other mouse interactions? In Skivvr, pressing Shift and clicking on the input will reset the input to its default or inherited value.
A nice touch would be to select a value when the user clicks an input the first time.
11/15
👉 Smart input options
Some inputs may support additional logic when the user uses them. For example, Skivvr color input supports putting name, HEX, rgba, hsl or hsb values (“red”, “#ff0000”, “rgba(255, 0, 0, 1)”, etc.) Size inputs support values like "10px" or "100%".
12/15
👉 Does an input need autocomplete or other select behavior?
Input can be used as a robust control to quickly select some values.
F.e. Font input completes a font name. This input has an arrow as well. Clicking on it will open a list of fonts, to select a font visually.
13/15
👉 Tab index:
Pressing "tab" in the input usually switches focus to the next UI control. Sometimes you want to code a specific order for this switching. For shadow selector, the order should be "X", "Y", "Blur", "Spread", not the "X", "Blur", "Y", "Spread"
14/15
And one more tip. If you use the input to rename something in-place, make sure that the input is correctly positioned, and use the same fonts settings to prevent an interface "jumps".
15/15
I haven't covered some points, mostly related to using inputs inside the forms. Feel free to add to this list! And thanks for reading 🙏
• • •
Missing some Tweet in this thread? You can try to
force a refresh
1/11
So, I reflected a bit about where I personally struggled as a solo founder and decided to make a micro SaaS targeted at us, fellow founders. I want to have everything you need to start and work on a project gathered in one place to #buildinpublic 🧵👇
2/11
I would be able to work on it for only 1-2 hours in the evening since I am highly coupled with my beloved 9-to-5 (no sarcasm 🙂). This actually influenced a design decision to separate an app into defined sections and to keep it simple to work in small iterations.👇
3/11
The project's codename is "TinyPlan", but I will change it as soon as I get something better. The key phrase I used to design the prototype's features is “as simple as possible.” The app is divided onto several sections:👇
2/11 Since now I am fully responsible for product decisions as well, I am seeing a bigger picture. For example, where and when I need to compromise on code quality to bring an #MVP faster.
3/11 Compromising on the code quality infuriates my inner developer :) So I need a way to calm the beast and make sure that everything will be stable enough to make it to the launch. One way to do that is by writing tests.
How to not get bored with huge tasks? Break those to smaller ones. #GTD#buildinpublic
I am implementing undo and redo functionality. I need to define an undo command for every possible action in the app. Making that in one bunch is pretty monotone and can lead to errors. More⬇️
I created a list of all possible actions and now treat undoing every action as a separate small task. Now I can mix them with other tasks, still keeping track of what should be done for a big “undo” story. ⬇️
Keeping tasks tiny diminishes another problem: context switching. Because there is not much context to switch with small tasks :) ⬇️
Creating a #SaaS#NoCode tool with real-time collaboration possibilities is quite the challenge, and there are a few resources that are helping me.
First of all — an awesome @figmadesign blog. I was thrilled when I read figma.com/blog/how-figma… — it has inspired me to work on a collaborative tool in the first place, and it has been my main source of insight about multiplayer.
Figma though is freer in its data structures since it does not use an existing technology of working with layouts. In my case, I need to comply with HTML and CSS. Some CSS properties, for example, backgroundImage, are not atomic — they could hold multiple values at the same time.