Hacker News Reader

Comment by seanwilson | Hacker News Reader

> In discussions like these, there's usually at least one person who shows up to demand data or research, but curiously never presents anything to back up their own claims about modern UI superiority.

It's easy to make fun of particularly bad modern examples, but I personally think people really take for granted that the baseline of usability for many areas has hugely increased over the last 20 years.

My recollection of some things that made older GUIs less usable, especially for non-techy people: vital functionality had to hunted for in menus or (much worse) right-click context menus, annoying modals everywhere, scary technical language, having to read the manual, lack of undo/redo/autosave, complex install processes, information overload sometimes, confusing file systems (like c:\ and weird file extensions), sharing and collaborating on files was cumbersome.

This is really obvious if you've ever had to help friends/family use something over the phone, as you realise how much knowledge you have to build up to confidently use some software.

It's really amazing what non-techy people can easily do on their phones and computers now, like real-time collaborative editing of a document (with automatic saving and unlimited undo) over a video call. Things like this used to be a nightmare to setup and use, and now it's taken for granted.

View on HN

The menubars of yesteryear could get out of hand sure, but I’m not convinced that the patterns that came to replace them are clear wins.

For instance, menubars at least have the benefit of standardized behavior between programs and platforms. To me that’s better than what we frequently have today, where it’s not unusual for functions to get buried 3 modals deep with zero commonality between programs, aside from maybe involving a hamburger menu (which doesn’t benefit from being a standard, because it’s a junk drawer with contents varying dramatically between apps).

AutoCAD is a great example of menu bar explosion. You have tens of thousands of potential buttons if you loaded up everything.

Button spam ends where CLIs begin. When something truly becomes that complicated, it's time to embrace text commands.

AutoCAD does have a command line, though. The most common commands have names one or two characters long, and you can use Space instead of Enter, so it's really comfy, you can dedicate one of your hands entirely to the mouse, and use the keyboard with the other one.

Once activated, these commands start asking for arguments, which you can select with similar short abbreviations, or pick a point with the mouse.

You also have customizable toolbars, which can be placed both horizontally and vertically around the drawing area, and you can pick which buttons you want exposed and which you don't need (often).

The menus are mostly to help you explore the available functionality while you are still a beginner. Also, having a fixed location for a piece of functionality makes it easier to refer to it in a book, for example.

This was twenty years ago, though. I remember there was a push to make it more Windows-looking with every new release (It's Unix native, IIRC). Maybe, by now, it's a joke. I don't know.

> The menus are mostly to help you explore the available functionality while you are still a beginner.

Yes, this is one of the most valuable parts of a proper menu system: it’s basically an index of everything a program can do, and it can even be made searchable (like the menus of any app using the native menubar on macOS is).

Menus are also an amazing hook point for accessibility utilities and make things like implementing a HUD UI that works across apps (like Ubuntu’s Unity did) trivial.

Yes like having a command palette (in vs code, intellij and now in chrome) really helps.

Or in Emacs for 40 years.

Calling the 'hamburger' a 'junk drawer' is just so apt!

Often one clicks it out of hope rather than expectation.

I mentally "tch" (the annoyance sound) whenever I go to GitHub or other sites to login, and then open KeePassXC, and the login button hides behind their junk drawer just because my window resized (tiling window manager).

There is still screen space to put it outside, ffs. Right next to the "Sign Up" button. Your 32x32px logo surely doesn't need all that padding, does it?

> the baseline of usability for many areas has hugely increased over the last 20 years.

I genuinely think the opposite has happened. Most of the things you cite as being problems with UI of the 2000s is really better applied to software of the late 80s/early 90s, although in all eras there have been both fantastic and terrible UIs.

But from a usability perspective, I think things peaked in the early 2000s.

> It's really amazing what non-techy people can do easily on their phones and computers now

It truly is! But that's about functionality improving, not about usability improving.

A few years ago, my then employer, due to a certain client's requirement, had everyone take a certification course on application security. One of the things that stuck in my head was the course advocating for cryptic error messages. The reason given was that the message shouldn't highlight a particular kink in the armor (if you will) that an able hacker could then try to exploit. Too vague and cryptic was best.

I admit, it makes a lot of sense. Annoying as a user, but necessary for application safety and security.

That's just security-by-obscurity and doesn't actually buy you anything except a speed bump for a hacker. It was a bogus argument from proprietary software vendors against open source a couple of decades ago, and it is a bogus argument for web services, too.

The presence of an error at all is a tell for the hacker as they search the surface area of the service's API, making the wording unclear is simply anti-user (sometimes quite literally when these errors are used as part of anti-fraud measures and shut down accounts without informing the user of what they even did wrong).

I mean showing the exact path to the configuration file likely isn't a good idea, so there is likely a mix of user friendliness and avoiding information leakage.

You can't avoid showing the exact path to the configuration file. When your software opens the file, that's visible.

Yeah, I love the linux "File not found" without a file name and path that was searched.

It does a lot more to prevent fixing bugs rather than prevent exploiting them.

> I mean showing the exact path to the configuration file likely isn't a good idea

Why? This is not self-evident to me.

Now I should say in web facing applications, not user ran applications on a computer. Maybe that makes more sense.

The messaging to the user should be actionable, so the exact filename going to them doesn't make any sense, but giving them a clear sentence of what exactly went wrong and what should be done to fix it if possible, or a UUID (or "Guru Meditation" value if you're feeling old school) to give to the helpdesk that can then be used to look up all of the relevant information on the other side is reasonable.

We were talking about obfuscating what the user did wrong and giving them a misleading message to somehow improve security. Saying that giving them information they can't actually use (like the path to a configuration file in a proprietary web service) is what we're discussing is moving the goalposts.

I think this is probably taking the advice about not letting people on the sign-in window know if a username/email exists in the service or not (to determine whether or not it is worth spending the time trying a list of potential passwords for another user and access data they shouldn't) and expanding it without understanding the nuance. Before they have signed in you don't know who or what is accessing the login path and therefore there's much less confidence that it's a legitimate user. Once the login is successful and that auth token is being used, though, the confidence is much higher and obfuscating details of the relationship between the company and that particular user is pretty strictly anti-user since the user can no longer be certain if the implicit contract of services provided will continue as expected or not. (Couple that with network effects, migration costs, etc, and the relationship becomes even more lopsided.)

There's a difference between "hey user, don't do that" and something going wrong under the hood.

And you don't think anti-fraud teams use error logs triggered by users as a signal for potentially banning them?

These teams are incentivized to eliminate fraudulent accounts that cost the company money and are pressured/punished when their tools produce false-negatives (fraudulent users that are considered okay), but get no such pushback on false-positives (okay users that get flagged as fraudulent), and accounts that are triggering errors in the backend service(s) can look a lot like someone actively trying to hack it. Basically any sort of anomalous behavior that correlates with negatives for the business get flagged by these tools, and doing so unjustly is not an explicit goal, but it isn't really punished within the corporation.

(The false-positives do get negative feedback in the rare instances when it blows up on social media, so these teams often include a whitelist of high profile accounts to just skip over but still impact the regular users capriciously, only "solving" the false-positive problem insofar as it impacts the business.)

If the user is authorized to take the action, and the error in question isn't related to authorization or authentication, then the error message should be clear and actionable.

The action may be "contact support" with a trace ID, but it should still be clear. When it's something the user can fix, and the application already knows the user is permitted to do what they're trying to do, the application should provide as much information as it can to help them complete the task.

it's also about usability improving because touchscreen models of interaction are less complicated to reason about than mouse based interactions.

on edit: really HN, after the years of articles showing computer illiterate people using ipads and phones for tasks they were not using computers for, probably seeing plenty of 1 year olds able to use ipads etc.

you're downvoting someone for pointing out touchscreens are easier to understand than using a mouse.

> vital functionality had to hunted for in menus or (much worse) right-click context menus

Those are bad, but magic touch-sensitive areas are even worse. The article mentions scrollbars as a clear example.

> scary technical language

This could be bad, but frankly a technical error or code that you can google is a lot less bad than a generic "oopsy whoopsy something broke".

> This could be bad, but frankly a technical error or code that you can google is a lot less bad than a generic "oopsy whoopsy something broke".

Technical language where it's appropriate is fine. For errors, it's easy enough to show a friendly error message at the top with more technical details underneath if it could be useful.

Actually, I forgot about double-clicking which was everywhere on Windows. People would be confused about if single or double-click would do something different and when to do which.

> For errors, it's easy enough to show a friendly error message at the top with more technical details underneath if it could be useful.

What exactly is the point of an error message being "friendly"?

Does a sad cartoon face with an "Oops" in a speech bubble make users feel better? No. Not really. Because the user wants the thing to function, and if it doesn't, the user may want someone to help him, and if all that someone gets to work with is a little cartoon picture, that's not going to result in a happier user.

If there is an error´ in my app, I make it EASY for the user to see, copy and send it. Yes, I have written apps where an exception results in the stacktrace to be displayed in the actual app.

You know what these "unfriendly" errors caused? Countless very happy users, whos problems were quickly solved by knowledgable stuff who got actual error messages and stacktraces to work with.

> People would be confused about if single or double-click would do something different and when to do which

And did double clicks go away as a result? No. No they did not.

And btw. neither did Menu bars. We still have them. Only now, we have them IN COMBINATION with ribbons etc. and they are sometimes themselves hidden behin dsome element.

I mean friendly in the sense "Use human-readable language. Error messages should be plainspoken using legible and readable text (many writing apps can give you feedback on a message's readability). Avoid technical jargon and use language familiar to your users instead. The Web's most common error message, the 404 page, violates this guideline. Hide or minimize the use of obscure error codes or abbreviations; show them for technical diagnostic purposes only.":

https://www.nngroup.com/articles/error-message-guidelines/

> And did double clicks go away as a result? No. No they did not.

Double click has largely went away, yes. I see double click in desktop file managers still but it's mostly gone elsewhere. It never became a thing on touch screens because it's not discoverable (which is why it's not great on desktop either) and it's very rare to see in web interfaces. Related:

https://blog.codinghorror.com/double-click-must-die/

https://www.nngroup.com/articles/when-to-open-web-based-appl... ("Double-Click")

> It never became a thing on touch screens because it's not discoverable

Is that why? Discoverability on touch screens has been deprioritized in most other respects, why would this one thing be special?

Besides hidden scrollbars, do you have examples of lack of discoverability on touch screen? Any specific apps?

I can't relate to this to be honest, I feel confident on my phone that main features are either right in front of me via a tap and less common features are behind a visible menu icon. Think how much worse it would be if double tap and long tap were required for common workflows. Some apps do require gestures but they either onboard you or the gestures are optional.

> I can't relate to this to be honest, I feel confident on my phone that main features are either right in front of me via a tap and less common features are behind a visible menu icon. Think how much worse it would be if double tap and long tap were required for common workflows. Some apps do require gestures but they either onboard you or the gestures are optional.

Not my experience at all. Snapchat famously made their UI deliberately undiscoverable so that only people who made an effort would find all their features; I don't know if Instagram deliberately copied that or not but a whole lot of its functionality requires blindly tapping somewhere that's not obvious to tap or dragging somewhere that's not obvious to drag (e.g. going backward or forward in a story, messaging someone).

My favourite example is pasting a phone number into the dialer on Android: you have to long press on the blank white input, and it will only even show the context menu if you've got a phone number on the clipboard already. A couple of versions back it was worse: you had to long press in the correct half of the featureless white rectangle, otherwise it would just silently not work.

> Avoid technical jargon and use language familiar to your users instead.

The problem with that: Such messages are rarely helpful in diagnosing and actually fixing the problem, which is the point of error messages in the first place.

The 404 Error message is short, precise, and (unless the server misuses HTTP codes), tells me EXACTLY what is wrong: 404: Resource not found. The thing that the URL I entered denotes, isn't there.

That is a helpful error message. "Oh dear, oh dear, it didn't work." however, is a crap error message, and the only thing it accomplishes, is enraging both users and technical support staff.

> Double click has largely went away, yes. I see double click in desktop file managers still but it's mostly gone elsewhere.

Please do tell, where else was it used to begin with, where it no longer is?

> It never became a thing on touch screens because it's not discoverable

a) It never became a thing on touchscreens because there is no mouse on touchscreens

b) There were, and still are, apps that use double taps

> which is why it's not great on desktop either

Please, do tell, how would you differentiate, in a file browser, between marking an item, and opening an item?

> My recollection of some things that made older GUIs less usable, especially for non-techy people

It's of course entirely possible that usability has increased in some areas and decreased in others. That's more or less my assessment of the situation summarized in a single sentence.

Also, there's a difference between "usability" and "easy to get started with". They're not the same thing at all! "Having to read the manual" can make an application MORE usable if it allows for more advanced UI paradigms, and for applications where the users will spend a lot of time this can be a good trade-off (of course, for many other types of applications it's a bad trade-off).

It's hard to directly compare things to 20 years ago; "real-time collaborative editing of a document (with automatic saving and unlimited undo) over a video call" wasn't done because we lacked the internet speeds and computing power to make that viable, not because UI paradigms improved.

> It's hard to directly compare things to 20 years ago; "real-time collaborative editing of a document (with automatic saving and unlimited undo) over a video call" wasn't done because we lacked the internet speeds and computing power to make that viable, not because UI paradigms improved.

But that's not true. 2003, 20 years ago, happens to mark the launch of both the first modern collaborative real-time editors (SubEthaEdit and MoonEdit) and a major video calling service (iChat AV).

Sure, hardware progress since then has helped. Video calling got much better due to internet, camera, and codec improvements, along with webcams becoming a ubiquitous component of computers rather than an external addon. Collaborative editing really took off once it started to work in web browsers, originally with EtherPad, but more importantly with Google Docs. That's partly due to the UI paradigm of the URL, but the ability for collaborative editing to work in web browsers can also ascribed to faster CPUs, as well as browsers getting more efficient (which is not hardware but also not a matter of UI paradigms).

Still.

Ignoring the calling part (which really isn't essential, IMO), collaborative editing isn't necessarily very resource intensive (depending on the algorithm). The technical conditions for it to work were satisfied as soon as Internet access became a ubiquitous feature of computers in the late 90s. Yet it wasn't until 2010, when Google Docs gained collaborative editing, that it even started to take off. I'd say that's definitely an example of UI paradigms improving over time.

By the way, a form of collaborative editing was shown off in 1968 in the Mother of All Demos, with video calling! It used analog video.

And AT&T had their (in)famous Picturephone way back in the 60s. But none of that is relevant or important here. Most people had nowhere near the bandwidth to make video chat usable.

Internet connections of the late 90 were absolutely not enough to support collaborative editing: the latency was just far too high, and more often than not connections were just not reliably enough, never mind that a huge section of people were on dial-up and paying by the minute (and many didn't have internet at all).

This really was a matter of actually having a critical mass of people with the hardware to do $stuff. Yes, all of this was "technically possible" a long time ago but a bunch of people in a research project isn't a market. After that things kind of sorted themselves out.

The thing with complex software is that yes, you have to explore it for some time before you could use it to accomplish your tasks. But after you did explore it, you'll have memorized where the actions you need are located. And probably their corresponding hotkeys too.

Technology requires education and getting used to before it can be used to achieve one's goals. It's perfectly normal. For some reason, no one questions the need to take driving lessons before being able to operate a car.

> but I personally think people really take for granted that the baseline of usability for many areas has hugely increased over the last 20 years.

I disagree.

What has happened, is that products that could get away with it, have hidden more and more functionality away, usually by shoving it into some god-awful hamburger-menu, or simply removed it, to not "confuse the users".

That's not improving, that's removing. And it's fruststrating for every power user, and everytime normal users leave the "happy path" the UI-gurus "designing" such things had in mind.

> scary technical language, having to read the manual,

Yes, people should try and understand the products they use. If they refuse to do so, then the obvious solution are simplified products, which, granted, are easier to understand, with the tradeoff of lacking functionality.

Which is completely fine by the way. Right tool for the job and all that. What isn't fine, is if ALL products start doing that, because then it gets really hard for the people who do read manuals to do their job...because suddenly there are no manuals any more, the language used is over-simplified and non-descriptive, and interface elements are god-knows-where.

And sadly, that's exactly where we are now in the software world. Because yes, things like a massive WYSIWYG editor is complex. There is no way around that complexity, not if you want it to have all these bells and whistles it's marketed for having. Yes, things like an email client that people organise their online-identiy around is complex. Yes, applications that people manage their financial lifes with have to be complex. No, an error message saying "Oh noes! Something's not working. Maybe try again later!" under the picture of some sad cartoon character is not helpful for tech support to debug problems.

My favorite example, and personal beef of mine? Firewall management software. Because, I think we both can agree that people who's job it is to manage corporate firewalls do read the manuals, and are not scared by technical language. But all my reading and being tech savy gets me absolutely nothing, if the only way to configure that thing is by running a click-marathon through what I can only assume was a modern-art design study gone horribly wrong, and the only documentation available is an old youtube video from 2 versions ago.

> as you realise how much knowledge you have to build up to confidently use some software.

Here is the thing though: In ye 'olde days, all these scary, techy interfaces looked the same. Once you figured out the menu bar in one application, it was easy to transfer that knowledge elsewhere. Want to save something? "File" menu. Want to change what you're working on? "Edit" menu. Want to change settings? Pretty sure there is a "Settings" or "Preferences" hidden somewhere under "Edit".

Nowadays, we have a hamburger button, or a 3-dot button, or a title bar, or a sidebar, or maybe it's one of the phones function buttons, or it's a 2-3-4-finger swipe (the directionality of which is anyones guess). The settings may or may not be under Account, or in the App-Settings, or there might not be any settings at all. The account can be reached helpfully via that gear-icon, or by clicking the profile picture, or by hovering over the profile picture and waiting 0.5sec for the dropdown menu to fly in. Or it's not there at all, because that would be scary to the users, and instead I can change account settings via the non-mobile website on my PC. Or via some other app. Oh, and how wonderful those interfaces are where certain elements only become visible when I flip the phone by 90°..

And this continues ad nauseam. There are no rules, no continuity, no obvious way how something works. Knowing how one app works, doesn't teach me anything about the next one, other than how great those ugly textual menu-bars were in comparison.

Lovely rant.

My least favorite feature of modern UIs: undiscoverable settings and options that only appear if you have enabled some other non-obvious option, are in some unspecified state, or, more typically the star are aligned.

My actually least favorite feature of modern UIs: doesn't matter if you actually learn to use it, because in two weeks it will change under you with on OTA update. And good luck finding documentation (third party of course) for the new redesign, because you are actually a guinea pig in an A/B test and most users do not have the same experience.

> Yes, people should try and understand the products they use. If they refuse to do so, then the obvious solution are simplified products, which, granted, are easier to understand, with the tradeoff of lacking functionality.

I was talking about being forced to read a manual because the UI wasn't obvious enough when it could have been made obvious without making the UI worse e.g. making features more discoverable by taking them out of right-click menus, preferring single click to double click, removing _unnecessary_ jargon, optimising the UI for common workflows, informative tooltips, better onboarding on the first-run, allowing undoing mistakes (vs warning modals or no undo at all), avoiding modals, auto saving/restoring state so you can continue where you left off.

I really think people take for granted how much better UIs do this stuff now because best practices have improved.

"Read the manual" and (as another comment suggests) "no one questions the need to take driving lessons before being able to operate a car" were common sentiments at the time that blamed the user and excused software for being better.

> Because yes, things like a massive WYSIWYG editor is complex. There is no way around that complexity

Obviously I'm not saying to dumb down complex professional software and stick all menu options in hamburger menus. I'm talking about software that casual non-techy people would often use. Complex software is a whole other design challenge.

I would argue that e.g. VS Code has a lot of UI improvements over Visual Studio though.

It would make more sense if you considered some of the better UIs of today, rather than the worst.

> really think people take for granted how much better UIs do this stuff now because best practices have improved.

We had these things figured out in the late 90s already.

    - Menus were single click, and hierarchially organised
    - The hierarchy was similar between programs
    - Everything was text, no one had to guess what "tiny arrow inside a box" means
    - Everything looked the same, because everything used the same widgets
    - Common functions were placed in menus that were labeled the same across applications
    - Menu-Items were directly labeled with their shortcuts if they had any
    - Hover-Tooltips have been a basic widget of GUI libs for ages

Sure, they didn't win any design awards, but they worked. In all their boring, obvious blandness, they worked, and they were easy to use. And that's the most important thing.

> removing _unnecessary_ jargon

Please tell me what is "_unnecessary_ jargon" in things like "File", "Edit", "New", "Preferences", "Save As...", "Tools", "Layout" or "Help"?

> I'm talking about software that casual non-techy people would often use.

As am I. These problems plague many many popular apps as well. Where is the account setting? Behind my profile picture? In a sub-hamburger? In the App-Settings? Where is the sub hamburger? Topright, mid-bottom, only visible when the display is in landscape mode? Do I have to swipe the menu in? If so, from which direction and with how many fingers?

That professional complex software is plagued by this as well is a personal gripe for me as a tech person, but these problems are universal.

I gave examples of specific best practice trends that are more common now compared to before. I didn't say everything is better so I'm not sure where your rant is targeted and it would help if you could interpret more charitably.

I agree menus, predictable locations for features, and keyboard shortcuts are great. You're again comparing the best of then to the worst of now though.

Standards for things like this will likely settle in over time. When apps now need to have support for touch + trackpads + mouse + keyboard, mobile/tablet/desktop screens, and multi-platform (Mac, Windows, iOS, Android, Linux), it's really shaken things up and made it much harder to agree and standardise on common patterns.

> You're again comparing the best of then to the worst of now though.

No, I am comparing what was common then to what's common now.

Granted, the menu structure of apps back then was in large part common, because there was only the desktop, and GUI programming was still in its infancy, so everyone used the same widgets.

And no, I am not saying that everything back then was great. There absolutely were apps with shite interfaces. Only it was a lot harder to justify them.

> Standards for things like this will likely settle in over time.

Some will, but since we made the transition from building interfaces to designing them, agreeing on standards became much much harder.

Because now interfaces are the playground of marketing, brand recognition, product identity and design fads. Even explaining how an app works can be hard, because the person asking me could be in another group in some godamn A/B test and have a different one, even though we use the same App.

> When apps now need to have support for touch + trackpads + mouse + keyboard, mobile/tablet/desktop screens, and multi-platform

That certainly makes it more difficult, and requires careful consideration for different platforms.

So riddle me this: Why was common the reaction of all these different requirements to suddenly pretend everyone is using a phone for everything all the time?

Because that's how many apps and websites now look: Like something designed for a small phone screen and navigation by thumb. I open a website on a 4K monitor with a laser-precision pointing device, and I get an information density comparable to the intergalactic void.

> So riddle me this: Why was common the reaction of all these different requirements to suddenly pretend everyone is using a phone for everything all the time?

It's very resource intensive and challenging to design multiple interfaces is the obvious answer here. Designing a website with just a few interactions that's accessible, supports mobile and desktop screens, and works in all browsers is already challenging and time consuming enough. Asking for almost a separate interface for different screen sizes and more costs significant resources that many won't have.

> Because that's how many apps and websites now look: Like something designed for a small phone screen and navigation by thumb. I open a website on a 4K monitor with a laser-precision pointing device, and I get an information density comparable to the intergalactic void.

What websites and apps in particular? I agree lazy mobile ports exist and are bad but I'm not experiencing this often with my daily apps and websites.

> It's very resource intensive and challenging to design multiple interfaces

Sure is. Wanna know why? Because there is no unversal standard on how to do it.

And arriving at such a standard is really really difficult, in no small part because of all the "amazing" design ideas I mentioned before, which are not only fast-and-ever-changing, but also don't work well together.

In ye'olde days, the problem was approached from the technical side: Technically, designing graphical interfaces is hard, so here is a constrained system that gives you these well defined methods for doing so. That's what design gets to play with, so that's the standard. It didn't look cool, and didn't lend itself easily to branding etc. but it worked. In fact it worked so well, that we STILL have ALL the UX elements from these days in active use today, and they STILL WORK.

Nowadays, we are in a situation where we try and approach the problem from the other side: Technical limitations basically went away, so everyone is free to design his own stuff, leading to a cambrian explosion of conflicting principles and ideas, including ideas how to standardize and categorize all of it.

If we were able to get this under control and design universal widgets that can automatically adapt to whatever device they are used on, that would be wonderful. And there are amazingly intelligent people who are trying to do that. But all that effort flies out the window the very next time some design studio or company want a nice juicy piece of personal brand recognition and "design" the next-shiny-thing.

>the baseline of usability for many areas has hugely increased over the last 20 years

But the baseline for functionality has decreased at the same time; usability has come at the cost of removing useful options in favor of lowest common denominator, not 80/20, more like 50 and "a very bloated 10...GiB".

OK-Cancel is gone, changes now are instaneous. Cancel was a useful thing to do.

You like that things have gone they way they've gone? That's great! I wouldn't dream of taking that away from you.

But why I can't I have mine work the way I like? Why do you support smashing everything into very small smooth round cookie cutters with one cookie recipe?

Reply on news.ycombinator.com