That's awesome! And agreed, there is nothing better than natural fit/wom marketing. Congrats!
936 karma · joined January 26, 2010
I'm working on a book as well, but for the Frontend. I'm very curious to know more about how you marketed this?
I know it's a different niche, but is there any globally applicable advice you'd give?
A general framework that has helped me a lot in the past.
The site in general is in 'under construction' mode right now, so rest assured these issues will all be resolved by launch. We're just dedicating all of our energy towards the first version right now, so have not polished everything.
You might be spending a bit too much time on the problem here. It may be worth spending a bit more on the solution and making that clearer.
Right now it seems that its hidden within the modal underneath the copy. It should be much higher and not within a modal.
I would also try to say more with less with the problem. Again, it felt like it took a little too long to get to the point (and the point you're making is a pretty good one I might add!).
I find that with people who are more on the 'founder' end of the customer spectrum, particularly those who are tech focused, too much 'copy' and 'slow salesmanship' can be a negative. We tend to err on the side of 'just tell me and I'll figure out if its valuable' if that makes any sense.
I hope this helps?
Good luck man!
Tapha
It tries to make planning a website or mobile app as close as possible to the pen and paper experience.
It does this in a simple but (from my, and the experience of those who have tested it out) very effective and engaging way.
I share a bit more about how this is done here: https://simpleprogrammer.com/information-architecture-develo....
There's no better way to put your mind into 'listening mode' than to assume that the person in front of you might know something that you don't.
Be humble, and listening will come naturally. The rest is just getting a better memory/knowledge base for better understanding.
The advantage of Tailwind [1] is very subtle over the short term (such as not having to constantly context switch between HTML & CSS files), but dramatically impactful over the long term.
Both in terms of time-savings, as well as code quality and ability to work with others quickly.
It really is something that you must earnestly try to gain an appreciation for.
My initial reaction was the same as the authors when I first came across it. Actually using it on a real life project changed my mind.
[1] - https://planflow.dev/blog/the-main-advantage-of-tailwindcss.
I *HIGHLY* recommend it.
Some tips:
- Understand that a drawing is a low fidelity synthesis of an idea.
The first skill to get good at, is breaking down what you're trying to say into its 'essence'. The most important PARTS of it.
This comes with practice, but a good way to do it is by writing, and then editing that writing, strangely enough.
- Learn the fundamentals of design
Understanding the basics of design, such as color theory, typography and layout composition gives you a great advantage when it comes to your drawing technique. There is no secret here, you will just have to learn the basics and then practice.
- Use FAST tools
I use Figma for all of blog drawings [1]. Why? because it's online, and most importantly, it's very FAST. And fast helps me speed up my iteration (and therefore 'learning') cycles. Fast is highly underestimated when learning. Fast is a superpower.
- Use templates
If you take a look at the drawings I have on my blog, you'll notice that I use similar templates for each one. In fact they all start from the same template.
Using a template gives you the confidence to get over the 'blank page' anxiety that often derails beginners. Allowing you to build up a momentum that will KEEP you drawing. And if you keep drawing, you WILL get better.
I plan to write more about this in the next few weeks, as a blog post. If you're interested in reading it, select one of the posts on the blog [1] and add your email address at the bottom! :)
Hope this helps!
An article that talks about how to overcome this (and that many have found useful): https://planflow.dev/blog/how-to-get-better-at-css
Everything else that you build into the skill set will be built around this. So definitely worth starting with.
[1] - Kathy Sierra "Badass" https://www.amazon.com/Badass-Making-Awesome-Kathy-Sierra/dp...
It's the guardian at the gates.
People are just more willing to give their attention to things that are novel. Which is of course based on context.
It's also one of the reasons why I've taken to using drawings within my own blog posts [1]. I've seen time on site that is MUCH higher than industry benchmarks.
Maintaining this perspective of what designers are in function will probably lead to better designers (via the form of their work) overall.
Is another fantastic one.
I'm really getting into the idea that design is basically all about guidance. Mapping a goal-worthy journey for the user. Which is why we use words like 'journey' and 'story' often when describing UX issues.
Thanks for the comment and the link! Very enlightening.
I really really like this quote. Did you come up with this? Hits the nail right on the head, and is actually a key to helping developers better understand how to design effectively. Namely, to come at design from the perspective of an interface as an 'information architecture'. And how this is key to making design easy and more understandable for a engineering oriented mind.
I wrote a short article about this here: https://simpleprogrammer.com/information-architecture-develo....
It's called "How To Debug CSS"[1], if you go through my post history, you'll get a good idea of the backstory behind it.
Essentially, what I'm trying to do is help developers like you (who are like me, or at least how I was), in that I knew CSS for a long time, but never really felt like I 'got it', in the same way that I 'got' many of the other aspects of web development.
I've now gotten to a point where this is almost the complete opposite. I now feel like I have gained a certain level of mastery over CSS. And most of it had to do with a simple change of perspective.
Here's an article I wrote as sort of a subset of the book, that covers a lot more about how you can truly start to get better at CSS, as a developer: https://planflow.dev/blog/how-to-get-better-at-css.
[1] - https://gumroad.com/l/Debbg/z823cp8 (I've added a pre-order discount code to the book for those interested).
What OP seems to be looking for is just a higher level of abstraction. So that there's less repetitiveness.
That's exactly what Tailwind does. And does VERY well.
Mobile phones started off as simply ways to call people. Are they not much more than that now? Would approaching them with only their original perspective be as helpful today?
No. The perspective has completely changed. Now, the more accurate one would be to approach them as full-blown computers.
> HTML is a single-root hierarchy whose only primary job is to display text and maybe some images. That's it and it pretty much sucks even at this job.
While HTML and CSS started in the ways that you've described. That's not what they are for now.
> Saying that CSS and HTML are meant to be used together to construct and architect pages is some serious re-writing of history and evolution of CSS and some impressive mental gymnastics.
I'm not rewriting history. I'm re-framing the CURRENT perspective of these technologies, in a way that is much more helpful. What use does framing HTML and CSS from the perspective of their origins have?
How does this help you create with it today?
With modern considerations that are more in the realm of architectural thinking than they were before?
A lot of the problem developers have with CSS, has to do with the way they see it.
Developers don't typically like to 'design' things in the artsy sort of way. But they do like to engineer them. CSS can be viewed from both of these perspectives very accurately.
The latter however, generates more enthusiasm for the developer. And enthusiasm is key to everything else.
It's more of a mental model with which to see it. If you view a webpage as something to be 'architected', rather than as simply something to be 'styled', every else you do (as well as how you feel when you're doing it) changes.
This is actually the misconception that leads to confusion with (and ultimately, poorly written) CSS.
It comes from a misunderstanding of what creating a web page actually is.
As Alan Kay once remarked, “A change of perspective is worth 80 IQ points.”
This is no less true with CSS.
Most developers view CSS an annoying 'styling' language, that's 'not really a programming language'. Which separates it in your mind from the engineering frame of view that tends to excite you as a developer.
This makes CSS tedious to use.
In truth, HTML and CSS are parts of a holistic language of layout construction. They work in unison, not as individual components. Very much an engineering toolset. Just that the problems to be solved are more visual in nature than you're probably used to.
Instead of seeing CSS as an annoying way to 'style' pages, see it instead as a visual programming language for constructing visual guides (UI's) for your user.
You don't 'style' pages, you 'construct' and 'architect' them. It sounds weird to use these words, but they have a massive effect in changing your perception of what you're doing. And that has a massive effect on your impression and willingness to learn how to do it well.
I think that understanding this is one of the key differentiators between developers who are good with CSS and those that struggle.
Tools like TailwindCSS (that lead to a massive increase in both productivity with CSS as well layout maintanability) are based on this fundamental premise.
I expand on this more in a recent post called "How To Get Better At CSS", which you can read here: https://planflow.dev/blog/how-to-get-better-at-css
Sidenote: I'm also working on a book that aims to help you gain mastery over CSS, showing you how to truly understand it, by learning how to debug its most common issues as well as re-framing how you see it in the way I've described above. You can check that out here: https://gumroad.com/l/Debbg/z823cp8.
If you target a specific group people initially, and make something 'for them'. As one of them. You place yourself in a much greater position to succeed than if you had simply made a game in the abstract in the terms of who it is for.
A great example of this is the FIFA franchise. And most of the football related franchises for that matter. It seems like if you meet the criteria of making a great game, as the OP has stated, failing within these categories is in some ways, harder than succeeding.
These are not easy concepts to digest without visual examples. I will try to edit my posts with some concrete examples to get them to be closer to the book.
One of the concepts I share in the book is on the idea of viewing HTML as a relational structure. Like a database. And how viewing it in that way helps you to better understand positioning (even with CSS). Because re-framing it in this way automatically gets you thinking about your elements, and the CSS that binds them, more holistically.
The most common way that people trip themselves up when working with HTML and CSS is by becoming myopic with regard to the specific section or element they're dealing with, and not seeing the whole forest so to speak. Making them unable to see why a problem in their CSS is happening.
Or to know what they need to do to create a certain thing in their layout.
A lack of a holistic understanding (how elements relate to other elements, and how CSS fits into this), and thereby view is what causes this.
My two latest articles goes into more detail re this: