Live data from Hacker News

Things I learned after getting users

basementcommunity.bearblog.dev

131–140 of 155 posts

Re: Things I learned after getting users

#131
post #123
post #94

Earlier quoted context omitted.

Agreed, seeing something changing out of the corner of my eye is very off-putting.

Hm, I can see where the criticism comes from. Is there a way to keep this feature that would make it more acceptable?

Personally I don’t think it’s worth the benefits over just having a TOC at the top of the page, as is otherwise customary. It’s different if this is a web site or web app where you have an account, and where users can permanently enable/disable it as an option when they prefer it. But on a public web page for a general audience, it always introduces friction by being visually distracting (because it doesn‘t scroll with the rest of the page), or by hiding due to responsive layout (requiring the browser width to be adjusted, or having to toggle it by mouse instead of scrolling to the top by keyboard), and so on.

Re: Things I learned after getting users

#132
post #131
post #123

Earlier quoted context omitted.

Hm, I can see where the criticism comes from. Is there a way to keep this feature that would make it more acceptable?

Personally I don’t think it’s worth the benefits over just having a TOC at the top of the page, as is otherwise customary. It’s different if this is a web site or web app where you have an account, and where users can permanently enable/disable it as an option when they prefer it. But on a public web page for a general audience, it always introduces friction by being visually distracting (because it doesn‘t scroll wi…

Fair point. I personally end up using those a lot, especially in articles that I skim (instead of reading end to end).

I'll start collecting data on its use, because people on the orangey site (including me) tend to have opinions that don't represent the average user.

Re: Things I learned after getting users

#134

Earlier quoted context omitted.

i'm more sad to see founders repeatedly put out ugc-oriented software or communities without any design priority for safety. safety is the hard part of ugc products but is left to figure out after scale and ossification.

How would you plan for 'safety' in UGC-oriented software? I'm actually interested in this.

I have a lot of thoughts on this that I plan to start writing on under indiedevstack.com before long, for now you can follow my one biz social where I will promote it once ready @manabiSRS

But some quick references... One approach is to avoid algorithmic surfacing of UGC outside of one's own network (or secondary connections etc), which makes discovery harder (must be compensated in other ways). Twitter may explore similar ideas with pluggable algorithms (though I don't trust them). Another approach is to constrain UGC: eg a music/audio community which has barriers to sharing new audio outside your network, but which freely allows remixing and promoting remixed audio of known good audio without as much safety control over the remixes because the operations allowed on the "good" source material make it difficult to subvert. This kind of idea is at the core of a product concept, not an additional layer to tack on later. I believe that finding these kind of cheaper ways of managing UGC and lending discovery to UGC can be a huge competitive edge.

Re: Things I learned after getting users

#135
post #30

"this is mostly because i relied on a SQL ORM which in short is a tool that makes writing SQL easier to pick up and faster to develop. the biggest downside is that it might execute 50 queries to your database to get a list of information, when it probably only needs 1, which will cause slowdown." I appreciate this honesty. Listen to this old man's advise: learn SQL properly. It's not that hard. Focus on it for a few…

I'm happy to write my own SELECT queries, but it sucks to be manually schlepping row[0], row[1], etc. into the fields of my domain entities, or making sure I provide the parameters to the parameterized INSERT statement in the right order. ORMs usually let you drop down to SQL as desired, and I do that when I have a nontrivial query to express, but CRUD plumbing is nice.

Not sure which programming language you are using. For Java, I find Spring JDBC templates with Row Mappers more productive than ORMs. DataClassRowMapper will automatically populate the domain entity.

Re: Things I learned after getting users

#136
post #73

Earlier quoted context omitted.

And if you're going to do it, make it easy. Many sites have missed out on my thoughtful (not to say I'm 'right', but that even if they don't want to do it it's considered and reasoned) feedback simply because the process although offered requires a login (i.e. sign-up) or because the last time I tried I got some dumb email back thanking me for my question it's not really possible but I can work around it by (x y z th…

I always reply to feedback. Seems only polite.

Certainly, I've had some great even more thoughtful/in-depth replies too, it's just the ~zero effort template support-channel 'thanks for your question'/'unfortunately that's not possible today' type response - I know, that's why I gave the feedback; all it does is tell me it didn't get anywhere near the right person, which is a souring experience (and waste of my time & effort) and makes me wish there just hadn't been a feedback button to begin.

Re: Things I learned after getting users

#137

Earlier quoted context omitted.

How would you plan for 'safety' in UGC-oriented software? I'm actually interested in this.

I have a lot of thoughts on this that I plan to start writing on under indiedevstack.com before long, for now you can follow my one biz social where I will promote it once ready @manabiSRS But some quick references... One approach is to avoid algorithmic surfacing of UGC outside of one's own network (or secondary connections etc), which makes discovery harder (must be compensated in other ways). Twitter may explore s…

Hey man, thanks. Really interesting. I've added indiedevstack.com to my bookmarks, so I'll check in that once you've launched

Re: Things I learned after getting users

#138
post #99
post #30

"this is mostly because i relied on a SQL ORM which in short is a tool that makes writing SQL easier to pick up and faster to develop. the biggest downside is that it might execute 50 queries to your database to get a list of information, when it probably only needs 1, which will cause slowdown." I appreciate this honesty. Listen to this old man's advise: learn SQL properly. It's not that hard. Focus on it for a few…

Honestly, I started on the ORM hate train when I first started and wrote my own queries in an effort to be "performant", but my frankenstein of writing direct queries and abstracting code to be reusable became basically a super shitty ORM that was a nightmare to maintain for a large codebase lol. I don' think there's anything wrong with it and for 90% of CRUD actions it's what you should choose. By the time you hit p…

I'm wired differently.

Even if I'd run a database operation just on a local machine and it takes 100x more load than an optimized SQL query, I still care. It's craftsmanship.

Sounds like you may have a case of the abstraction disease. You keep reaching for abstractions that never accomplish the actual benefits of a truly solid abstraction.

Re: Things I learned after getting users

#139
post #49
post #30

"this is mostly because i relied on a SQL ORM which in short is a tool that makes writing SQL easier to pick up and faster to develop. the biggest downside is that it might execute 50 queries to your database to get a list of information, when it probably only needs 1, which will cause slowdown." I appreciate this honesty. Listen to this old man's advise: learn SQL properly. It's not that hard. Focus on it for a few…

> learn SQL properly. It's not that hard. Focus on it for a few weeks intensely and you've mastered it for life. Exactly the same is true of ORMs. I find most of the people who advocate "just use SQL" have a bizarre aversion to applying the same learning effort to their ORM. > I've had weekends ruined troubleshooting my "highly productive ORM layer" that nuked a production database. Whilst functionally speaking my OR…

"That kind of problem happens with regular SQL all the time"

Well, no, it doesn't. I told you to learn SQL properly. When you do, you know what a query plan is. Which is something you'd rarely need if you know how to design a database and its indices.

All of this would be covered in every beginner's book.

Re: Things I learned after getting users

#140
post #49

Earlier quoted context omitted.

> learn SQL properly. It's not that hard. Focus on it for a few weeks intensely and you've mastered it for life. Exactly the same is true of ORMs. I find most of the people who advocate "just use SQL" have a bizarre aversion to applying the same learning effort to their ORM. > I've had weekends ruined troubleshooting my "highly productive ORM layer" that nuked a production database. Whilst functionally speaking my OR…

"That kind of problem happens with regular SQL all the time" Well, no, it doesn't. I told you to learn SQL properly. When you do, you know what a query plan is. Which is something you'd rarely need if you know how to design a database and its indices. All of this would be covered in every beginner's book.

I'm aware of what a query plan is. I can see that the query plan is wrong. There's nothing I can do about it, since I took the standard advice on HN and used PostgreSQL as my database.

Meanwhile if you'd applied the same "learning it properly" standard to your ORM you would never have had the problem you described.

Post reply on HN