Steve Austin. The 6 Million Dollar Man. Lindsay Wagner. The Bionic Woman. I couldn't get enough of either of them when I was a boy. I imagine that the bionic woman coming out later, when I was entering puberty, would explain why I had the hots for Lindsay Wagner, especially when she ran in slow motion in that Pocohontas outfit. And I imagine that my referring to him as Steve Austin rather than Lee Majors is because I so wanted to identify with him. Steve. Perfect name for a bionic boy.
I was slogging through some college football schedules today, just trying to get a better handle on this wonderful season that has finally blown in. Slogging. I went to several popular news outlets like espn and foxsports. Both are loaded LOADED with information. The info is well-presented, colorful, and hyperlinked. But, it was a slog for me. Why?
Why are facebook and twitter and mmorpg's and porn and candy crush and farmville and whatever the latest corny games are such a time sink? And why was their predecessor, ebay, such a time sink? In my opinion it's because we are all bionic. Our brains and eyes are so much faster and more powerful at processing information than programmers have understood. And computers are weak at doing things like humans. As a result the computing interfaces we've ever seen have been awkward and time-consuming to us.
This might be hard to accept because of how infatuated we are with computers and computing devices like smart phones, tablets, laptops, and other shinies. They're so fast. They do so much. They bring so much information to our fingertips (until the latest cellular broadband gets flooded and has to be scrapped and replaced again--1G, 2G, EV-DO, EDGE, 3G, 4G, LTE--good grief, the history of cellular networks is like the history of the razor blade. I think we're on 5G with razor blades now). But, our infatuation is misplaced. Yes, computers have raw processing power, all those mips. But they don't process information the same as our brains. Our brains are bionic. They're OP.
Going back to the college football schedules, what I wanted to find was a very quick way to scan the whole season, jump to any team's schedule, see their rank, get team and opponent analysis, see the point spreads for today's games, see very quickly what times and what channels on MY tv the games are to be televised, and anything else I could think of. To be sure, all of this information exists. It absolutely exists. Out there. On the internet. I just have to hunt for it. And that's the time sink I'm talking about. And it's why there are experts at this field. The experts are the ones spending their whole life hunting and gathering this information. Hunter/gatherer. Primitive.
Our brains are capable of processing so much information in such a short time. And they are very sensitive to very small things. Things computers are light years from understanding. The best movie actors act with their faces, and they don't overact or we call that comedy. A small narrowing of the eyes can convey an emotional bouquet that would take millions of words to describe. Our brains process that without the words, without if/thens or flowcharts, or other computing constructs. Or, think about when you're driving in your car on a road that's new to you, looking for a destination that's new to you. There's a lot of fatigue. That same road, after you've driven it a few times, is relaxing, and the time goes by faster. There are millions and millions of pieces of information being processed by your brain the first time you drive that. Not just the speed limit and warning signs and traffic conditions. The leaves on the trees. The colors. The smells in the car and coming in off the road. The vibrations and bumps felt. The sounds of the car, the road, the radio. The blood in your veins. Heartbeat. Blood pressure. Digestion. Detox. Sweat. Tears. Breath. Conversations before the drive. Concern over kids, retirement, aging parents, lost love, all those other things that are occupying brainpower on the back burner, sliding forward at interesting intervals.
So what do I want from the college football sites, and from all web sites and all computer programs? I want a firehose. I want what Neo got in the matrix with the training programs. That thing is the least fiction of any science fiction I have ever seen. But, it will never happen. Why? Money. All of the Money have taken over information technology and their vested interest is in creating time sinks. facebook wants you spending hours and hours and hours on their site. Games use clever techniques to trap your mind. Other web sites do it clumsily and maybe inadvertently, thinking that they are organizing information well, but still trap us uselessly for hours. And porn, well, yeah. These digital all stars are the new predators. Predators that prey on bionic minds. They are the new boob tube. The new idiot box.
We are bionic. In cages of digital kryptonite.
Saturday, August 30, 2014
Monday, August 25, 2014
what he used to look like
I was reading a post that included a picture of the blogger at the bottom. I thought, I wonder how aged that picture is. And then I thought, every picture is what someone used to look like.
Social. I hate the term. Old people think they're so cool when they say it. But, the likes of facebook and pinterest and instagram and even facetime offer a promise of pictures of who people are, not who they were, as they shorten the timeline of picture development and distribution. It's a false promise.
Every picture is what someone used to look like. Just like these words are what I used to think.
Every picture is what someone used to look like. Even celebrities, even yours, even mine, even God's.
Social. I hate the term. Old people think they're so cool when they say it. But, the likes of facebook and pinterest and instagram and even facetime offer a promise of pictures of who people are, not who they were, as they shorten the timeline of picture development and distribution. It's a false promise.
Every picture is what someone used to look like. Just like these words are what I used to think.
Every picture is what someone used to look like. Even celebrities, even yours, even mine, even God's.
Wednesday, August 20, 2014
Beyond mobility and modern apps
The problem with “mobility” and actually all applications is
this. We need to move away from monolithic applications that are rules-based
and very rigidly architected and towards applications that are more fluid,
agile, and even evolutionary.
If you consider the classic example of an order management system, the rigid structure is plain. There are orders. Each order has properties associated with it like date, time, sales agent. Order details have information about the individual items ordered, their status regarding availability, price, cost, quantity, and the like. Order headers usually summarize this information into totals. The desktop app usually allows a subset of orders to be chosen according to security access, and then allows the user to select an individual order to see its header information and totals, and then allows the user to drill down into the header to see the details for the individual items on the order. And then, the user can sometimes do things with the individual items or even the whole order like cancel it, approve it for release from inventory, send it to shipping, or back-order certain items. The so-called modern app, which is device-centric, can implement this functionality easily. SAP Fiori , for example, targets this particular app squarely. Both modern apps and desktop apps can do this the same way, and it will work.
But, one of the problems that either platform has is the ability to pare down the work and get the user quickly to the right order or set of orders. The way both solutions implement this is with filters. The user needs to know in advance what filter to use to get the ones she wants to work with. The developer or IT department can help by pre-configuring some common filters like “open orders with a ship date within 5 days”, “orders with at least one item on back-order older that is 1 week past the original ship date” and the like. The problem has always been that if there are not very many orders, the app works easily and delightfully. But then again, if there are not many orders then a pen and paper can run the business. However, if there are many orders, the user might spend most of their time just trying to filter for the right orders or scroll through a large list looking for the right orders, so that they can finally enjoy the experience of “swipe-right-tap-once-and-you’re-done” that is so “delightful”. We need to move away from all this. What we need is for the apps to be allowed to learn and evolve so that they automatically surface to us what we care about and what we need to decide.
I’m not sure if this goes firmly under the category of Artificial Intelligence (AI) or not. If you think about the way humans learn from an early age, it might help. A child learns that some things are bad and others good. Bad things could be inherently bad or artificially bad. I touched the stove and burned my hand. That was bad (inherently). I hit my sister and got sent to timeout. That was bad (artificially). I swam in the cool pool on a hot day. That was good (inherently). I ate all my meat and so I got pudding. That was good (artificially). One of the differences between computers and humans is in the way we decide. Computers can iterate through enormous sets of data and analyze each one in a very tedious, monotonous way to come up with a definitive selection. Humans cheat. We use intuition, hunch, prior experience, elimination of nonsense, and the like, to arrive at answers quicker. We process a lot of information but not in the same way computers do. I believe the answer to getting the most out of modern apps is to teach them the concept of good and bad, and empower them to use their iteration skills to arrive at the same place as humans so that we work together, so that the device is an extension of the human.
For example, if the computer (browser, phone, tablet, whatever) is allowed to know that back-orders are bad. Back-orders that are older than a week past the original ship date are worse. Back-orders for our most important customers are worse. Back orders where there is a comment on the order about someone canceling our contract and giving all their business to our competitor is bad, even if it’s not a week past due. And it’s also bad if that comment is on the customer master record or another order from the same customer, or on another customer in the system who is really the same as this customer even though they have a different customer number.
In monolithic systems the software doesn’t evolve. The developers evolve. What I mean is that the software gets released. If it’s modern software it gets continually released by making agile updates every week or so. As the app is field tested new conditions are learned, more complexity is modeled, and richer functionality is included. Things like bad back-order situations. But, bad back order situations being discovered and hard-coded into the apps by humans is inefficient. It’s not what humans are inherently good at doing, which is why it takes so long in the field to achieve this level of app maturity. What we need is to teach the computer things that are bad (have negative consequences or are unpleasant), and unleash them to find those and surface them to us so that together we can avert them. What we need is to teach the computer things that are good (reward us or please us), and unleash them to find those and surface them to us so that we can “swipe-right-one-tap” them together. This won’t be simple, but this is what needs to happen.
First, the computer is going to have to know some basics about what business is. These are customers. We want to make them happy. When we have a customer we put them into the database and assign them a number. But a customer could have lots of numbers because sometimes we have a sell-to customer, and ship-to customers, and sometimes customers are just addresses or people that have special meanings depending on what app is using them. They all work together to help us serve our customer well, which is GOOD.
Next, the computer needs to be free to traverse all the data in the system and surface things to us like, “Hey Jane, are these customers related? They’re not linked on the customer master screen, but they have very similar names. They are? Ok, them I’m going to add that to my black book of customer relationships for future reference.” There are many implications of this type of interaction. For example, another app could come and look at that discovered information in the black book and suggest merging and restating all the history, and then retiring the customer that was erroneously added when someone couldn’t find the correct customer (because the human couldn’t spell the original customer’s name). Or, once these discoveries are made, the app might come along be allowed to realize that there are several large orders, related to a customer, that are all back-ordered, or that are all set to arrive at the same time, and suggest, “Hey John, you might want to call this customer and let them know what they’re about to deal with.”
Compare this paradigm to something like “Boom Beach”, an app available for iOS. There are good things and bad things that can happen to your civilization. Good: “Commander, your troops are ready.” Bad: “Home base raided.” Good: “Home base defended.” Bad: “Village lost.” In this case the computer knows what things are considered good or bad, and surfaces them. It’s fairly simple to do because there are a limited set of conditions that are good or bad due to the limitations of the game.
For business, there could be many more, and much more complex conditions that are good and bad, but when the conditions are found they can be surfaced in much the same way. Check these orders. Call these customers. Review these mishaps and take action. Again, this problem can be solved in two ways. Solve it monolithically by field testing the app and updating the top-down code to be more and more complicated to handle the newly discovered conditions. Solve it modernly by allowing the computer to evolve. It goes without saying that trusting the computer with concepts of good and bad, and asking it to surface actionable conditions only will have problems: some conditions will be missed and some conditions will be non-issues that clutter the app and waste time. But, this is the next frontier, and once we get this to work fairly well there will be an acceleration of app innovations possible. Until then all we're doing is working bloodshot developers around the clock to create the illusion of apps that are delightful, and under-utilizing computing power.
If you consider the classic example of an order management system, the rigid structure is plain. There are orders. Each order has properties associated with it like date, time, sales agent. Order details have information about the individual items ordered, their status regarding availability, price, cost, quantity, and the like. Order headers usually summarize this information into totals. The desktop app usually allows a subset of orders to be chosen according to security access, and then allows the user to select an individual order to see its header information and totals, and then allows the user to drill down into the header to see the details for the individual items on the order. And then, the user can sometimes do things with the individual items or even the whole order like cancel it, approve it for release from inventory, send it to shipping, or back-order certain items. The so-called modern app, which is device-centric, can implement this functionality easily. SAP Fiori , for example, targets this particular app squarely. Both modern apps and desktop apps can do this the same way, and it will work.
But, one of the problems that either platform has is the ability to pare down the work and get the user quickly to the right order or set of orders. The way both solutions implement this is with filters. The user needs to know in advance what filter to use to get the ones she wants to work with. The developer or IT department can help by pre-configuring some common filters like “open orders with a ship date within 5 days”, “orders with at least one item on back-order older that is 1 week past the original ship date” and the like. The problem has always been that if there are not very many orders, the app works easily and delightfully. But then again, if there are not many orders then a pen and paper can run the business. However, if there are many orders, the user might spend most of their time just trying to filter for the right orders or scroll through a large list looking for the right orders, so that they can finally enjoy the experience of “swipe-right-tap-once-and-you’re-done” that is so “delightful”. We need to move away from all this. What we need is for the apps to be allowed to learn and evolve so that they automatically surface to us what we care about and what we need to decide.
I’m not sure if this goes firmly under the category of Artificial Intelligence (AI) or not. If you think about the way humans learn from an early age, it might help. A child learns that some things are bad and others good. Bad things could be inherently bad or artificially bad. I touched the stove and burned my hand. That was bad (inherently). I hit my sister and got sent to timeout. That was bad (artificially). I swam in the cool pool on a hot day. That was good (inherently). I ate all my meat and so I got pudding. That was good (artificially). One of the differences between computers and humans is in the way we decide. Computers can iterate through enormous sets of data and analyze each one in a very tedious, monotonous way to come up with a definitive selection. Humans cheat. We use intuition, hunch, prior experience, elimination of nonsense, and the like, to arrive at answers quicker. We process a lot of information but not in the same way computers do. I believe the answer to getting the most out of modern apps is to teach them the concept of good and bad, and empower them to use their iteration skills to arrive at the same place as humans so that we work together, so that the device is an extension of the human.
For example, if the computer (browser, phone, tablet, whatever) is allowed to know that back-orders are bad. Back-orders that are older than a week past the original ship date are worse. Back-orders for our most important customers are worse. Back orders where there is a comment on the order about someone canceling our contract and giving all their business to our competitor is bad, even if it’s not a week past due. And it’s also bad if that comment is on the customer master record or another order from the same customer, or on another customer in the system who is really the same as this customer even though they have a different customer number.
In monolithic systems the software doesn’t evolve. The developers evolve. What I mean is that the software gets released. If it’s modern software it gets continually released by making agile updates every week or so. As the app is field tested new conditions are learned, more complexity is modeled, and richer functionality is included. Things like bad back-order situations. But, bad back order situations being discovered and hard-coded into the apps by humans is inefficient. It’s not what humans are inherently good at doing, which is why it takes so long in the field to achieve this level of app maturity. What we need is to teach the computer things that are bad (have negative consequences or are unpleasant), and unleash them to find those and surface them to us so that together we can avert them. What we need is to teach the computer things that are good (reward us or please us), and unleash them to find those and surface them to us so that we can “swipe-right-one-tap” them together. This won’t be simple, but this is what needs to happen.
First, the computer is going to have to know some basics about what business is. These are customers. We want to make them happy. When we have a customer we put them into the database and assign them a number. But a customer could have lots of numbers because sometimes we have a sell-to customer, and ship-to customers, and sometimes customers are just addresses or people that have special meanings depending on what app is using them. They all work together to help us serve our customer well, which is GOOD.
Next, the computer needs to be free to traverse all the data in the system and surface things to us like, “Hey Jane, are these customers related? They’re not linked on the customer master screen, but they have very similar names. They are? Ok, them I’m going to add that to my black book of customer relationships for future reference.” There are many implications of this type of interaction. For example, another app could come and look at that discovered information in the black book and suggest merging and restating all the history, and then retiring the customer that was erroneously added when someone couldn’t find the correct customer (because the human couldn’t spell the original customer’s name). Or, once these discoveries are made, the app might come along be allowed to realize that there are several large orders, related to a customer, that are all back-ordered, or that are all set to arrive at the same time, and suggest, “Hey John, you might want to call this customer and let them know what they’re about to deal with.”
Compare this paradigm to something like “Boom Beach”, an app available for iOS. There are good things and bad things that can happen to your civilization. Good: “Commander, your troops are ready.” Bad: “Home base raided.” Good: “Home base defended.” Bad: “Village lost.” In this case the computer knows what things are considered good or bad, and surfaces them. It’s fairly simple to do because there are a limited set of conditions that are good or bad due to the limitations of the game.
For business, there could be many more, and much more complex conditions that are good and bad, but when the conditions are found they can be surfaced in much the same way. Check these orders. Call these customers. Review these mishaps and take action. Again, this problem can be solved in two ways. Solve it monolithically by field testing the app and updating the top-down code to be more and more complicated to handle the newly discovered conditions. Solve it modernly by allowing the computer to evolve. It goes without saying that trusting the computer with concepts of good and bad, and asking it to surface actionable conditions only will have problems: some conditions will be missed and some conditions will be non-issues that clutter the app and waste time. But, this is the next frontier, and once we get this to work fairly well there will be an acceleration of app innovations possible. Until then all we're doing is working bloodshot developers around the clock to create the illusion of apps that are delightful, and under-utilizing computing power.
Subscribe to:
Posts (Atom)
-
Apple's new bags when you buy something in an Apple Store are biodegradable. The old bags were thick plastic and threaded with a rope dr...
-
Love won't be held hostage. Love takes no prisoners.
-
Did you ever know anyone who seemed to have no trouble making choices? The thing I'm thinking about now is that we all make choices ever...
