taphangum

That's awesome! And agreed, there is nothing better than natural fit/wom marketing. Congrats!

Fascinating!

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?

There was an interesting thread about this on Twitter a while ago: https://twitter.com/PlanFlowDev/status/1317680078734696448

You may find this helpful: https://fromtoschool.com/why-most-programming-tutorials-are-....

A general framework that has helped me a lot in the past.

Thanks man. Yes, we've had some issues on Safari for a while now (seems like its the new Internet Explorer :)). I'll take a look at this.

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.

Alright, so what you have here is pretty innovative. The problem for me was that it just took way too long for me to figure out what it is you did.

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

Awesome! Thanks chdaniel. Happy to give you feedback. Check back in a few.

https://planflow.dev - The easiest way to PLAN your website or mobile app.

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....

Humility.

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.

"If you can suppress the urge to retch long enough to give it a chance, I really think you’ll wonder how you ever worked with CSS any other way.” - Adam Wathan

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've been doing this for my own blog posts (https://planflow.dev/blog) of late, as well as within my book (https://gumroad.com/l/Debbg/z823cp8), and I have to say, the engagement levels are INSANE.

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!

[1] https://planflow.dev/blog

A big reason why many developers struggle with CSS is because they view it as an afterthought. And never truly learn the fundamentals.

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

I don't know any courses personally. But highly recommend the book Badass by Kathy Sierra[1]. It won't necessarily tell you everything you need to know about product management. But it will tell you what you need to about really creating good product. Which is the core of the product management skill set.

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...

Fantastic definition.

You don't get to talk to the prefrontal cortex without first getting past the hind-brain.

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.

[1] https://planflow.dev/blog/how-to-get-better-at-css

This would be very useful.

Males took more risk and therefore died in places that would more likely preserve their fossils?

Ironically (as I'm sure you're aware), your comment is the perfect example of form follows function.

Maintaining this perspective of what designers are in function will probably lead to better designers (via the form of their work) overall.

communicate don't decorate

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.

Design must be subservient to usability.

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....

I'm actually working on this, releasing it in about a week or so (doing the final edits).

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).

100% this.

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.

Languages (and technologies in general) evolve. And as they do, it's helpful to evolve your perspective towards them alongside it.

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?

Have you ever found that your enthusiasm towards something changed once somebody explained it to you from a different perspective?

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.

Semantics do actually matter quite a bit. They are what ultimately determine your frame of reference, and ultimately, how you use a thing.

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.

I had been referencing someone else with another quote initially, forgot to remove that part. My mistake! Have now edited to fix.

I know, many folks love css, but I find it a big mental discontinuity from html and js. It's solving a different problem

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.

While I agree that making games in general is a bit of crapshoot, I think that there is a way that you can increase your chance of success. Based on what I understand from creating businesses in general.

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.

I appreciate the feedback. The reason why it feels like this is because I haven't included any real CSS based examples here (which I do in the book) of what I mean.

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.

Happy to expand.

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:

https://planflow.dev/blog/how-to-get-better-at-css

https://planflow.dev/blog/what-makes-css-hard-to-debug