3 ms·

> made through repetitive use now who's entrapping who? you think its practical for every piece of software to be a massive time sink? > software that litera

> made through repetitive use now who's entrapping who? you think its practical for every piece of software to be a massive time sink? > software that literally wastes their limited time they have on this planet. There's a saying "linux is only free if you don't value your time", now you're saying that software that takes MORE time commitment saves you time? C'mon, take off your engineering hat for a second.

TeMPOraL 6y ago
I'm saying that: 1) Actual value to people is mostly created in software that's being used repeatedly. The tools people use for work, to run their errands, and to communicate. 2) For any tool that's used repeatedly, if there's no path for the user to grow ever more proficient and efficient in using it, the tool is wasting that user's time. > now you're saying that software that takes MORE time commitment saves you time? No, I'm saying that less time spent on using software to accomplish unit of value is better. For software used repeatedly, this is achieved by learning to use the software better - and that can only happen if the software offers room to grow, and isn't just a Fisher-Price toy.
- ZephyrBlu 6y ago
  You are assuming there is zero opportunity cost in learning to use the software better. Perhaps further increasing my efficiency with this software is not as impactful as spending my time on something else. This also assumes that the time you invest in learning the software will be offset by productivity gains, which seems extremely unlikely for the majority of users assuming the software is non-trivial. There is also risk associated with learning the software. What if you begin to learn it and then for some reason you stop using it? You've just wasted a whole lot of time.
  - TeMPOraL 6y ago
    All three of your points are covered by my base assumption: software used repeatedly. Any opportunity cost is consumed by the fact you're using this software all the time. For the same reason, productivity gains compound, and there is little risk of switching any time soon (also this is the kind of experience that tends to generalize well).
    - ZephyrBlu 6y ago
      Repeatedly != all the time. You can repeatedly use software (I.e. daily, monthly, yearly) for short periods of time or for specific tasks. That doesn't mean you'll be using it all the time though. I think most users fall into this category rather than people who use it "all the time". A lot of the time people just use software to get the job done and aren't engrossed in using it. If I can improve my efficiency/revenue/whatever metric more by leveraging something other than this software, why would I waste my time learning how to use the software better?
      - TeMPOraL 6y ago
        > You can repeatedly use software (I.e. daily, monthly, yearly) for short periods of time or for specific tasks. That doesn't mean you'll be using it all the time though. Yes, and perhaps I should've clarified that I meant "repeatedly" as in "couple hours or more a week, on average". With an important caveat that software which is used "for short periods of time or for specific tasks" by some people all too often is also used all the time by other people. E.g. I use Word or Blender for about an hour a month on average, but there are many people who spend eight hours a day, five days a week in front of them. It's bad if you handicap the former for the sake of the latter. > A lot of the time people just use software to get the job done and aren't engrossed in using it. The difference I'm trying to focus on here: if you're using the software once, to do one-off job, there's no point in you investing into learning it. But if you're using the software to do a job done on a regular basis, you'll eventually start looking for ways to spend less time doing that job. It's nice if software offers such ways, and guides you towards them. > If I can improve my efficiency/revenue/whatever metric more by leveraging something other than this software, why would I waste my time learning how to use the software better? Fair. I'm explicitly talking about situations where you can't. You have a job to do, this is the software that lets you get it done. If you can use different software to do it faster, then of course you should use it.
- devmunchies 6y ago
  > For software used repeatedly, this is achieved by learning to use the software better I'll do you one better. for software used repeatedly, it is better to completely automate the task (if possible). It sounds like your goal is to empower users. The higher goal, imo, is to unencumber users. I see you're a Lisp man so I get where you're coming from (elegant extensibility — I'm an OCaml + F# man myself), but IMO the beauty of software is the ability to remove human interaction, not increase it. And any interaction that is unavoidable should be minimal. Innovation is the ability to reduce to the minimum viable components without sacrificing functionality.
  - TeMPOraL 6y ago
    (EDIT: sorry for the wall of text :). TL;DR: I agree with your point, and below I elaborate on software that can't entirely automate your work away.) -- And I do agree! Software that can completely automate the task is the best! It's just that it's really hard. Where we could've done this, we've already done this. What remains is software dealing with tasks that cannot be fully automated[0] - tasks that require human decisions as input, decisions the software can't reasonably guess in advance. For such software, there are two axes of interest here: how many decisions are there to be made, and how complex/consequential they are. These are inversely correlated to some degree - the big decisions (like how to repartition your hard drive or whether to sound a missile alert) tend to not be made very often[1], and they benefit from UI that trades safety for speed. My focus was the other type - the one that requires lots of individually small decisions. The type that's used repeatedly throughout the day or week. In such software, you're guiding the computer towards a particular outcome, or a series of outcomes. The decisions involved are simple: what letters to type, when to send a message, what vertices to select, what transformation to apply, where to position items, what columns to sum, etc. The computer can't guess your goal here - often you don't know the goal yourself. You're in a feedback loop with your work, mediated through software. And it's best if that loop can be as tight as possible. The limit to how much this loop can be tightened is the level of comfort of the user. Initially, they'll want to make every step manually. Type every letter. Click on every icon (making sure to first hover and read textual help). But soon, it gets tiring. People don't think about tasks in terms of "type 'hello<ret>'", "look where the column starts, where it ends, type '=SUM(A2:100)<ret>'". They think in terms "say 'hi'", "sum this column", "make this stuff be there". Sometimes we can predict these, we can put "smart compose" or a sum button in our software. We can add support for clipboard, autocomplete. Thus starts the "featuritis", so dreaded by modern web UX people. They're often misunderstanding the problem as having features, but the problem to solve is how to reveal the features at the right time, when the user is ready for them. From there, there are two ways to improve still. One, ergonomics. At some point your user will be tired of having to click around to do everything. They make decisions much faster than they can input them. Software is best when it can operate at the speed of thought[2]. So why not add discoverable keyboard shortcuts? Users who reach this stage will be happy to discover they can input their decisions faster, if they don't have to hunt buttons in the UI. Their level of comfort will rise too, because they don't have to break themselves out of their flow[3]. For more advanced users still, here is where tuning enters the picture. Predefined ergonomics may be almost right, but not quite. It's nice when the user can change the defaults to better suit themselves and their particular work. Two: composition. At some point, the user grows from thinking about each low-level decision individually to thinking about them in aggregate[4]. In a way, they DRYed up their steps into a procedure. The software thus can get better if it lets the user define this procedure somehow, and then invoke it on demand. In the limit, this means coding, but for most cases, it doesn't have to. At the very least, it means batch operations. If the user has to make the same few steps on a series of items, let them input these decisions once, and apply to the selection. This little feature can transform a work day[5]. And you can go further. Could the user save their search query? Could they combine that saved search with the batch feature? Could you turn "selecting a query and applying batch operation to it" into a higher-level batch operation[6]? Will everyone need all such features? No. But various users will find themselves using some of them - the ones that fit well with their needs and their level of comfort. The job of UX design is then to make users more comfortable with advanced features. Making them easier to discover, test and learn, so that they can save more time. But for that to happen, the software first needs to have those features. It needs to have the room for users to grow. -- [0] - Without human-level AI. [1] - Except. At least when it comes to dealing with computers, a decision that's very important for your personal machine may be totally inconsequential for a cluster of VMs - so as a software author, you may want to have an "escape hatch" for batch, noninteractive work. Noninteractive work is something that comes up in all types of software, as it can let a tool gain many more use cases. [2] - Anything less is, again, wasting user's limited time on this planet. [3] - I realize I'm just making claims without providing any citations. I don't have any, at the moment. One of these days I'll dig into HCI literature. In the meantime, I'm just hoping everyone here both knows this from their personal experience and seen this with non-tech people at work. A familiar example that jumps to my mind is interacting with various clerks and officials. A cashier using a good ol' keyboard-based POS system, the one that runs in DOS, can input your order and print your receipt while simultaneously holding a conversation, and be done faster than it takes you to find your wallet. Similar cashier with a modern browser-based POS system will click around screens in full focus, and have you wait a minute or three before they can update inventory. It's also interesting how stores where throughput matters - e.g. supermarkets - end up wiring their modern POS systems to keyboards. [4] - Much like every driver has a point at which they stop thinking consciously about pedals and steering wheel and gear lever, and start thinking in terms of joining the traffic, changing lanes, overtaking - and eventually they just manifest their will through the car, while their hands and legs move themselves. [5] - I was once asked to help some people at a sales department of a small e-commerce company to update some of their listing on an auction site. It's a job they'd be doing every couple days, taking three people an hour or two. I poked around their management panel a bit, found a very well hidden button that allows doing batch updates, and showed them how one person can do that task in 15 minutes. How much time they could've saved if that button was a little bit more discoverable? And I'm sure that, the way it was placed, some "data whiz" at the management panel's vendor will look at the analytics, notice people don't click on this button much, conclude that users must not need it and decide to cut the feature out. The self-fulfilling prophecy of modern "data-driven" software development. [6] - And yes, ultimately, could you let the user just write code, and also expose the functionality in CLI for headless operations? These two things will definitely be niche, but will enable completely new use cases, potentially broadening your market. How many CLI scripts already exist on Github to do a half-assed job that could be done by popular software if the vendor thought about letting it be driven headlessly by an external script?

TeMPOraL 6y ago

I'm saying that: 1) Actual value to people is mostly created in software that's being used repeatedly. The tools people use for work, to run their errands, and to communicate. 2) For any tool that's used repeatedly, if there's no path for the user to grow ever more proficient and efficient in using it, the tool is wasting that user's time. > now you're saying that software that takes MORE time commitment saves you time? No, I'm saying that less time spent on using software to accomplish unit of value is better. For software used repeatedly, this is achieved by learning to use the software better - and that can only happen if the software offers room to grow, and isn't just a Fisher-Price toy.

ZephyrBlu 6y ago
You are assuming there is zero opportunity cost in learning to use the software better. Perhaps further increasing my efficiency with this software is not as impactful as spending my time on something else. This also assumes that the time you invest in learning the software will be offset by productivity gains, which seems extremely unlikely for the majority of users assuming the software is non-trivial. There is also risk associated with learning the software. What if you begin to learn it and then for some reason you stop using it? You've just wasted a whole lot of time.
- TeMPOraL 6y ago
  All three of your points are covered by my base assumption: software used repeatedly. Any opportunity cost is consumed by the fact you're using this software all the time. For the same reason, productivity gains compound, and there is little risk of switching any time soon (also this is the kind of experience that tends to generalize well).
  - ZephyrBlu 6y ago
    Repeatedly != all the time. You can repeatedly use software (I.e. daily, monthly, yearly) for short periods of time or for specific tasks. That doesn't mean you'll be using it all the time though. I think most users fall into this category rather than people who use it "all the time". A lot of the time people just use software to get the job done and aren't engrossed in using it. If I can improve my efficiency/revenue/whatever metric more by leveraging something other than this software, why would I waste my time learning how to use the software better?
    - TeMPOraL 6y ago
      > You can repeatedly use software (I.e. daily, monthly, yearly) for short periods of time or for specific tasks. That doesn't mean you'll be using it all the time though. Yes, and perhaps I should've clarified that I meant "repeatedly" as in "couple hours or more a week, on average". With an important caveat that software which is used "for short periods of time or for specific tasks" by some people all too often is also used all the time by other people. E.g. I use Word or Blender for about an hour a month on average, but there are many people who spend eight hours a day, five days a week in front of them. It's bad if you handicap the former for the sake of the latter. > A lot of the time people just use software to get the job done and aren't engrossed in using it. The difference I'm trying to focus on here: if you're using the software once, to do one-off job, there's no point in you investing into learning it. But if you're using the software to do a job done on a regular basis, you'll eventually start looking for ways to spend less time doing that job. It's nice if software offers such ways, and guides you towards them. > If I can improve my efficiency/revenue/whatever metric more by leveraging something other than this software, why would I waste my time learning how to use the software better? Fair. I'm explicitly talking about situations where you can't. You have a job to do, this is the software that lets you get it done. If you can use different software to do it faster, then of course you should use it.
devmunchies 6y ago
> For software used repeatedly, this is achieved by learning to use the software better I'll do you one better. for software used repeatedly, it is better to completely automate the task (if possible). It sounds like your goal is to empower users. The higher goal, imo, is to unencumber users. I see you're a Lisp man so I get where you're coming from (elegant extensibility — I'm an OCaml + F# man myself), but IMO the beauty of software is the ability to remove human interaction, not increase it. And any interaction that is unavoidable should be minimal. Innovation is the ability to reduce to the minimum viable components without sacrificing functionality.
- TeMPOraL 6y ago
  (EDIT: sorry for the wall of text :). TL;DR: I agree with your point, and below I elaborate on software that can't entirely automate your work away.) -- And I do agree! Software that can completely automate the task is the best! It's just that it's really hard. Where we could've done this, we've already done this. What remains is software dealing with tasks that cannot be fully automated[0] - tasks that require human decisions as input, decisions the software can't reasonably guess in advance. For such software, there are two axes of interest here: how many decisions are there to be made, and how complex/consequential they are. These are inversely correlated to some degree - the big decisions (like how to repartition your hard drive or whether to sound a missile alert) tend to not be made very often[1], and they benefit from UI that trades safety for speed. My focus was the other type - the one that requires lots of individually small decisions. The type that's used repeatedly throughout the day or week. In such software, you're guiding the computer towards a particular outcome, or a series of outcomes. The decisions involved are simple: what letters to type, when to send a message, what vertices to select, what transformation to apply, where to position items, what columns to sum, etc. The computer can't guess your goal here - often you don't know the goal yourself. You're in a feedback loop with your work, mediated through software. And it's best if that loop can be as tight as possible. The limit to how much this loop can be tightened is the level of comfort of the user. Initially, they'll want to make every step manually. Type every letter. Click on every icon (making sure to first hover and read textual help). But soon, it gets tiring. People don't think about tasks in terms of "type 'hello<ret>'", "look where the column starts, where it ends, type '=SUM(A2:100)<ret>'". They think in terms "say 'hi'", "sum this column", "make this stuff be there". Sometimes we can predict these, we can put "smart compose" or a sum button in our software. We can add support for clipboard, autocomplete. Thus starts the "featuritis", so dreaded by modern web UX people. They're often misunderstanding the problem as having features, but the problem to solve is how to reveal the features at the right time, when the user is ready for them. From there, there are two ways to improve still. One, ergonomics. At some point your user will be tired of having to click around to do everything. They make decisions much faster than they can input them. Software is best when it can operate at the speed of thought[2]. So why not add discoverable keyboard shortcuts? Users who reach this stage will be happy to discover they can input their decisions faster, if they don't have to hunt buttons in the UI. Their level of comfort will rise too, because they don't have to break themselves out of their flow[3]. For more advanced users still, here is where tuning enters the picture. Predefined ergonomics may be almost right, but not quite. It's nice when the user can change the defaults to better suit themselves and their particular work. Two: composition. At some point, the user grows from thinking about each low-level decision individually to thinking about them in aggregate[4]. In a way, they DRYed up their steps into a procedure. The software thus can get better if it lets the user define this procedure somehow, and then invoke it on demand. In the limit, this means coding, but for most cases, it doesn't have to. At the very least, it means batch operations. If the user has to make the same few steps on a series of items, let them input these decisions once, and apply to the selection. This little feature can transform a work day[5]. And you can go further. Could the user save their search query? Could they combine that saved search with the batch feature? Could you turn "selecting a query and applying batch operation to it" into a higher-level batch operation[6]? Will everyone need all such features? No. But various users will find themselves using some of them - the ones that fit well with their needs and their level of comfort. The job of UX design is then to make users more comfortable with advanced features. Making them easier to discover, test and learn, so that they can save more time. But for that to happen, the software first needs to have those features. It needs to have the room for users to grow. -- [0] - Without human-level AI. [1] - Except. At least when it comes to dealing with computers, a decision that's very important for your personal machine may be totally inconsequential for a cluster of VMs - so as a software author, you may want to have an "escape hatch" for batch, noninteractive work. Noninteractive work is something that comes up in all types of software, as it can let a tool gain many more use cases. [2] - Anything less is, again, wasting user's limited time on this planet. [3] - I realize I'm just making claims without providing any citations. I don't have any, at the moment. One of these days I'll dig into HCI literature. In the meantime, I'm just hoping everyone here both knows this from their personal experience and seen this with non-tech people at work. A familiar example that jumps to my mind is interacting with various clerks and officials. A cashier using a good ol' keyboard-based POS system, the one that runs in DOS, can input your order and print your receipt while simultaneously holding a conversation, and be done faster than it takes you to find your wallet. Similar cashier with a modern browser-based POS system will click around screens in full focus, and have you wait a minute or three before they can update inventory. It's also interesting how stores where throughput matters - e.g. supermarkets - end up wiring their modern POS systems to keyboards. [4] - Much like every driver has a point at which they stop thinking consciously about pedals and steering wheel and gear lever, and start thinking in terms of joining the traffic, changing lanes, overtaking - and eventually they just manifest their will through the car, while their hands and legs move themselves. [5] - I was once asked to help some people at a sales department of a small e-commerce company to update some of their listing on an auction site. It's a job they'd be doing every couple days, taking three people an hour or two. I poked around their management panel a bit, found a very well hidden button that allows doing batch updates, and showed them how one person can do that task in 15 minutes. How much time they could've saved if that button was a little bit more discoverable? And I'm sure that, the way it was placed, some "data whiz" at the management panel's vendor will look at the analytics, notice people don't click on this button much, conclude that users must not need it and decide to cut the feature out. The self-fulfilling prophecy of modern "data-driven" software development. [6] - And yes, ultimately, could you let the user just write code, and also expose the functionality in CLI for headless operations? These two things will definitely be niche, but will enable completely new use cases, potentially broadening your market. How many CLI scripts already exist on Github to do a half-assed job that could be done by popular software if the vendor thought about letting it be driven headlessly by an external script?