In addressing shortcomings of a major web browser
recently, I tossed out a neologism for a neologistic age: Minimum viable user.
This describes the lowest-skilled user a product might feasibly accommodate, or if you're business-minded, profitably
accommodate. The hazard being that such an MVU then drags down
the experience for others, and in particular expert or experienced users. More to follow.
cases where reasonable accommodations should be considered, absolutely. Though how this ought be done is also critical. And arbitrary exclusions for nonfunctional reasons -- the term for that is "discrimination", should you ask -- are right out.
Accessibility accommodations, in physical space and informational systems, is a key concern. I don't generally require these myself, but know many people who do, and have come to appreciate their concerns. I've also come to see both the increased imposition, and
benefits, this offers by way of accommodating the needs.
It's often underappreciated how increased accessibility helps many, often all, users of a product or space. A classic instance would be pavement (or sidewalk) kerb cuts -- bringing the edge of a walkway to street level, rather than leaving a 10 cm ridge. This accommodates not just wheelchairs, but dollies, carts, wheeled luggage, and more. Benefits which materialised only after deployment, beyond the original intent.
Accessibility and Information Systems
For information systems -- say, webpages -- the accommodations which are most useful for perceptually-challenged users are also
almost always beneficial to others: clear, high-contrast layouts. Lack of distracting screen elements. A highly semantic structure makes work easier for both screen-readers (text-to-speech) and
automated parsing or classification of content. Clear typography doesn't fix all copy, but it makes bad copy all the more apparent. Again, positive externalities.
When we get to the point of process-oriented systems, the picture blurs. The fundamental problem is that an interface which doesn't match the complexity of the underlying task is always going to be unsatisfactory. Larry Wall has observed this with regard to the Perl programming language: complexity will out. In landscape design, the problem is evidenced by the term "desire path
". A disagreement between use and design.
At its heart, a desire path is the failure for designer to correctly anticipate, or facilitate, the needs and desires of their users. Such paths reflect emergent practices or patterns, some constructive, some challenging the integrity of a system. Mastodon Tootstorms
are an example of a positive creative accommodation. Mostly.
On other services, the lack of an ability to otherwise dismiss content frequently creates an overload of the spam or abuse reporting mechanism. G+ comes to mind. If a side-effect of reporting content is that it is removed from my view, and there is no other way to accomplish that goal, then the reporting feature becomes the "remove from visibility" function. I've ... had that conversation with Google for a number of years. Or is that a monologue...
Software programming is in many ways a story of side-effects and desire paths, as is the art of crafting system exploits. PHP seems particularly prone to this, though I can't find the character-generating hack I've in mind.
There's the question of when a system should or shouldn't be particularly complex. Light switches and water taps are a case in point. The first has operated as a simple binary, the second as a variable-rate flow control, and the basic functionality has remained essentially unchanged for a century or more. Until the Internet of Broken Shit that Spies on you wizkids got ahold of them.... And modulo some simple management interfaces: timers or centralised large-building controls.
Simple tasks benefit from simple controls.
Complex tasks ... also
benefit from simple controls, but no simpler than the task at hand.
A good chef, for example, needs only a modicum of basic elements. A good knife. A reliable cooktop and oven. A sink. A cutting surface. Mixing bowls. Underappreciated: measuring equipment
. Measuring spoons, cups, pitchers. A scale. Thermometer. Timers. The chef also
may have call for some specific processing equipment: cutting, chopping, blending, grating, and mixing tools. Powering these increases throughput, but the essential controls remain simple. And some specialised tools, say, a frosting tube, but which generally share common characteristics: they're individually simple, do one thing, usually a basic transformation, and do it well.
The complexity of the process is in the chef, training, and practice.
The antithesis of this is "cooking gadgets" -- tools or appliances which are complicated, fussy, achieve a single and non-general
result, or which integrate (or attempt to do so) a full process. This is the stuff that clutters counter space and drawers: useless kitchen gadgets. A category so egregious it defies even simple listing, though you're welcome to dig through search results. If you can only use it on one recipe, it's bad mkay?
Appropriateness of Single-use Tools: Safety equipment
On single-use tools: if that single use is saving your life in conditions of readily forseeable peril
, then it may well be worth having. Lifeboats. Seatbelts. First aid kit.
That gets down to a risk assessment and mitigation calculation problem though, which may be error-prone: over- and under-estimating risks, and/or the efficacy of mitigations. Pricing risk and risk-as-economic good is another long topic.
Lifts, Telephones, and Automobiles
There are times when you absolutely should be aiming for the minimum viable user. Anything that sees widespread shared public use, for example. I shouldn't have to read the user manual to figure out how to open the front door to your building. Automatic, sensored doors, would be an entirely MVU product.
I've mentioned lifts, automobiles, and telephones. Each is highly complex conceptually, two can maim or kill. All can be relatively safely used by most adults, even children. A large part of what makes
lifts, automobiles, and telephones so generally usable is that the controls are very highly standardised. Mostly. The exceptions become newsworthy
Telephones have deviated from this with expansion of mobile and even more complex landline devices. And the specific case of business-oriented office telephones has been for at least 30 years, a strong counterexample, worth considering.
Office Phone Systems
It takes me a year or more to figure out a new office phone system. If ever. A constant for 30 years. This wasn't the case as of the 1980s, when a standard POTS-based phone might have five buttons, and the smarts were in a PBX generally located within the building.
By the 1990s, though, "smart phones" were starting to appear. Rolm was one early vendor I recall. These had an increasing mix of features, not standardised either across or within
vendor lines, but generally some mix of:
- Call forwarding
- Call conferencing
- Lots of other random shit to inflate marketing brochures
Feature #4 was a major problem, but the underlying one was, and remains, I think, the mismatch of comms channels and cognitive capacities a phone represents: audio, physical, textual, and short-term working memory.
The physical interface of most phones -- and I'm referring to desk sets here -- is highly constrained. There's a keypad, generally 12 buttons (not even enough for the impoverished Roman alphabet, let alone more robust ones), possibly an additional set of function buttons, and a handset, plus some base. Cords.
More advanced phonesets have perfected the technology of including a display for text which is simultaneously unreadable under any lighting conditions, viewing angles, or capable of providing useful information in any regard. This another engineering accomplishment with a decades-long record.
Phones are relatively good for talking
, but they are miserable for communication
. Reflected by millennials disdain for making phone calls
Millennials prefer text-based apps to voice comms, as do numerous tech early-adopters. I suspect the reason is both the state-maintenance and fragility of phone-based communications.
I'm distinguishing talking
-- a longer and wandering conversation with a friend -- and communicating
-- the attempt to convey or obtain some specific task-oriented or process-oriented information. The salient difference is that the latter is very strongly goal oriented
, the former, not so much. That is, a "simple" phone conversation is a complex interaction and translation between visual, textual, audio, physical, and memory systems. It's also
conducted without the visual cues of face-to-face communications (as are all remote comms), for further fun and games. This usually
makes conversations with someone you know well (for whom you can impute those cues) generally far more straightforward than with a stranger, especially for complex discussions.
The upshot is that while a telephone is reasonably simple to use in the basic case -- establish a voice connection with another device generally associated with a person or business -- it actually fails fairly profoundly in the surrounding task context
for numerous reasons. Many of which boil down to an interface which is simultaneously oversimplified and poorly suited to the task at hand.
Smartphones, and software-based telephony systems in general, followed the business phone lead.
Mobile comms generally have expanded on failures of business phone systems in poor usability as phones
by significantly deteriorating audio quality and dynamics -- constraints of packet-switching, compression, additional relay hops, and speed-of-light delays have boosted noise and lag to the level of interfering with the general flow of conversation. Which isn't particularly an interface failure as such (this is channel
behaviour), but it encourages the shift to text of millennials.
I'll save the question of how to fix
voice comms for discussion.
The point I'm making is that even an apparently straightforward device and task, with a long engineering history, can find itself ill-matched to new circumstances.
There's also much path-dependence here. Lauren Weinstein on G+ enjoys digging up old AT&T engineering and marketing and/or propaganda newsreels describing development of the phone system: direct-dial, switching, 7-digit, area-code, long-distance, touch-tone. There were real and legitimate design, engineering, and use considerations put into each of these. It's not as if the systems were haphazardly put together. This still doesn't avoid the net result being a bit of a hash.
An appreciation of why Mr. Chesterton built his fence
, and whether or not that rationale remains valid, is useful to keep in mind. As are path-dependencies, 2nd-system effects, and late-adopter advantages. Those building out interdependent networks after
initial trial often have a significant advantage.
It's also interesting to consider what the operating environment of earlier phones was -- because it exceeded the device itself.
A business-use phone of, say, the 1970s, existed in a loosely-integrated environment comprising:
- The user
- The phone itself
- A Rolodex
- The local PBX -- the business's dedicated internal phone switch.
- A secretary or switchboard operator, serving also as a message-taking (voice-to-text), screening, redirect, directory, interactive voice response, and/or calendaring service
- A desk calendar
- A phone book
- A diary or organiser
- Scratch paper
Critically: these components operated simultaneously and independently of the phone.
A modern business, software, or smartphone system may offer some, or even all, of these functions, but frequently:
- They aren't available whilst a call is in process
- They have vastly less capability or flexibility than the systems they replaced
The benefits are that they are generally cheaper, smaller, more portable, and create digital data which may
be, if accessible to other tools, more flexible.
But enough of phones.
The Unix Philosophy The Unix Philosophy
reads: "Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."
It offers a tremendous amount of mileage.
Exceptions to the Unix Philosophy: Complexity Hubs
I want to talk about the apparent exceptions
to the Unix philosophy: shells, editors, email, init (and especially systemd), remote filesystems, udev, firewall rules, security generally, programming languages, GUIs.
Apparently, "exceptions to the Unix philosophy" is very nearly
another neologism -- I find a single result in Google, to an essay by Michael O. Church
. He adds two more items: IDEs (integrated developer environments), arguably an outgrowth of editors, and databases. Both are solid calls, and both tie directly into the theme I had in mind in the preceding toot.
These are all complexity hubs -- they are loci of either control or interfacing between and among other systems or complex domains:
- Shells, editors, IDEs, and programming languages are all interfaces through which a skilled user interacts with a highly complex system. Whilst remaining in the context of text, this is a space in which new capabilities are themselves created or synthesised.
- Databases ... try to make sense of the world, under constraints of scale, consistency, performance, reliability, stability, integrity, and durability.
- Email faces a vast array of complexities: standards, remote systems and operators, file formats, spam, security, identity, DNS, filtering. And that's just on the technical side.
Within the communications context there are composing standards, workflows, language, characterset, prioritisation, archival, deletion, and more.
Email is, in a word, a hairball. It wants an Alexander.
- To a rough approximation, remote filesystems combine many of the technical complexities of both databases and email: sorting out who and what to access, via what standards, in a distributed context. None of the widely-used technologies is particularly satisfactory, and none of the satisfactory systems are widely used.
It's a CRUDdy situation.
- Linux's udev is at its essence the problem of remote filesystems made local -- the idea that devices directly attached (or made to appear to be directly attached) to a system might go walkabout or show up unexpectedly for dinner.
It is "responsible for providing an abstract interface of the hardware", which tells us what we need to know: When "abstraction" appears in docs, it's a warning that Here Be Dragons.
Simplicity doesn't need abstraction.
- Firewall rules and security generally are attempted as defences against the unexpected. Worse, they're very frequently contingent defences, which is to say, when you need a defence, you need it now. As in military contexts, your basic tools are limited: speed and agility, if you can get out of the way, shielding or armour, if you cannot, countermeasures, if possible. Given a comms context, rules of epidemiology also apply: guard your portals, or ports, with effective friend-or-foe.
Since attacks, particularly effective ones, are frequently unexpected, security is inherently a choatic space, and reflects it. It is highly resistant to attempts at organisation, though the focus on mechanisms, above, may help.
The GUI Mess
This leaves us with GUIs, or more generally, the concept of the domain of graphics.
The complexity here is that graphics are not text
. Or at the very least, transcend
text. It is possible to use text to describe graphics
, and there are tools which do this: Turtle. Some CAD systems. Scalable vector graphics (SVG). But to get philosophical: the description
is not the thing
. The end result is visual, and whilst it might be rule-derived, it transcends the rule itself.
One argument is that when you leave the domain of text, you leave the Unix philosophy behind. I think I'm OK with that as a starting premise. This means that visual, audio, mechanical, and other sensory outputs are fundamentally different from text, and that we need to keep in mind that text, whilst powerful, has its limits.
It's also to keep in mind, though, what the characteristics and limits of GUIs themselves are.
Neal Stephenson, "In the Beginning was the Command Line
", again, offers one such: Metaphor sheer. Most especially where a GUI is used to represent computer system elements themselves, it's crucial to realise that the representation
is not the thing itself
-- map-territory confusion. In fact a GUI isn't so much a representation
as a remapping
of computer state.
Unix, the C programming language, and the bash shell all remain relatively
close to machine state. In many cases, the basic Unix commands are wrappers around either C language structures (e.g., printf(1) and printf(3)), or report the content of basic data structures (e.g., stat(1) and stat(2)). Even where the concept is reshaped significantly, you can still generally find the underlying concept present. This may be more foreign for newbies, but as exposure to the system is gained, interface knowledge leverages to system knowledge.
GUIs lose this: represented state has little coherence.
Some argue that not being tied to the mechanism is an advantage -- that this allows the interface designer
a freedom to explore expressions independent of the underlying mechanism
This is true.
But it gets to another set of limitations of GUIs:
- There is a limit to how much information can be represented graphically, imposed by display, resolution, dot pitch, scrolling, seeking, and time.
- Users hate change.
- GUI efficiency is intrinsically limited.
- GUI doesn't script. Not easily. And most definitely not within the metaphor of basic GUI use, which is how CLI scripts.
Scripting has the effect of constraining, for better or worse, changes to interfaces because scripts have to be updated as features change
. The consequence is that tools either don't change arguments, change them with exceedingly long advance warning, or failing either of those, are rapidly discarded by those who use them due to gratuitous interface changes. The result is a strong, occasionally stifling, consistency over time.
The limits on information density and on scaling or scrolling are another factor. A good
GUI might offer the ability to expand or compress a view by a few times
, but it takes a very creative approach to convey the orders of magnitude
scales which, say, a physical library does. Data visualisation is its own specialty, and some are good at it.
The result is that most GUI interfaces are good for a dozen, perhaps a few dozens, objects.
Exceptions to this are telling. xkcd is on the money
This chart manages to show values from $1to $2.39 quadrillion ($2.39 thousand million million), within the same visualisation, a span of 15 orders of magnitude, by using a form of logarithmic scaling. This is possible
, but it is difficult to do usefully or elegantly.
GUIs, Efficiency, and Change
Change aversion and inherent limits to GUI productivity interact to create the final conflict for GUIs: the potential for interface efficiency is limited and
change is disruptive, you lose for trying. Jamie "jwz" Zawinski notes this
Look, in the case of all other software, I believe strongly in "release early, release often". Hell, I damned near invented it. But I think history has proven that UI is different than software.
What jwz doesn't do is explain why
this is, and I'm not aware of others who have.
This also shows up in the case of Apple, a company which puts a premium on design and UI, but which is exceedingly
conservative in changing
UI. The original Mac desktop stuck with its initial motif from 1984 until 2001: 17 years. It successor has changed only incrementally from 2001 to 2017, very nearly as long. Even Apple realise: you don't fuck with the GUI.
This suggests an underlying failure of the Linux desktop effort isn't a failure
to innovate, but rather far too much churn in the desktop
My daily driver for 20 years has been Window Maker
, itself a reimplementation of the 1989 NeXT desktop. Which is to say that a 30 year-old design works admirably. It's fast, stable, doesn't change unexpectedly with new releases or updates, and gets the fuck out of the way. It has a few customisations which tend to focus on function
rather than form
The Minimum Viable User GUI and Its Costs
Back to my starting premise: let's assume, with good reason, that the Minimum Viable User wants and needs
a simple, largely pushbutton, heavily GUI, systems interface.
What does this cost us?
The answer is in the list of Unix Philosophy Violating Tasks:
- Dealing with scale
- Dealing with complexity
- Iteratively building out tools and systems
- Rapid response
- Adapting to changing circumstance
- Considered thought
- Scalability of understanding, comprehension, or control
- Integrating numerous other systems
- Especially nonuniform ones
Just Who is the Minimum Viable User?
A central question, and somewhat inexcusably buried at this point in my essay, is who is
the Minimum Viable User? This could be the lowest level of system skills capable of using a device, which an OECD survey finds is abysmally bad
. Over half the population, and over 2/3 in most surveyed industrialised
countries, have poor, "below poor", or no computer skills at all
I'm moving past this point quickly, but recommend very strongly reading Jacob Nielsen's commentary on this study, and the study itself: "Skills Matter: Further Results from the Survey of Adult Skills
" (OECD, 2016). The state of typical user skills is exceedingly poor. If you're reading this essay, you're quite likely not among them, though if you are, the comment is simply meant without disparagement as a statement of fact: from high to low, the range of user computer skills is enormous, with the low end of the range very highly represented in the general population. People who, largely, otherwise function quite well in society: they have jobs, responsibilities, families.
This has profound implications for futures premised on any sort of general technical literacy. As William Ophuls writes in Plato's Revenge
, social systems based on the premise that all the children are above average are doomed to failure.
The main thrust of this essay though is a different concern. Global information systems which are premised on a minimal-or-worse level of sophistication by all users also bodes poorly, though for different reasons: it hampers the capabilities of that small fraction -- 5-8% or less, and yes, quite probably far less -- of the population who can make highly productive use of such tools, by producing hardware and software which fails to support advanced usage.
It does this by two general modes:
- It simply lacks the necessary features. I could point to the entirely crippled commandline userland of a typical Android device.
- It actively prevents advanced users from making full use of their devices by restricting access and enhancement. This might be seen as a patronising or Big Brotherish move by vendors, and there's certainly concern over this. But it's also a realistic response to the security and threat landscape of mobile devices operate in, given typical user skill levels. A fact hammered home by the fact that skilled users frequently fail to manage their systems securely.
The dynamics are also driven by market and business considerations -- where the money is, and how development, shipping, and maintaining devices relates to cash flows.
The Problem-Problem Problem
One business response is to extend the MVU definition to that of the Minimum Viable-Revenue
User: services are targeted at those with the discretionary income, or lack of alternatives, to prove attractive to vendors.
There's been well-founded criticism of Silicon Valley startups which have lost track of what a meaningful problem in need of solution. It's a problem problem. Or: The problem-problem problem
Solving Minor Irritations of Rich People, or better, inventing
MIoRP, as a bootstrapping method, has some arguable utility. Telsa Motors created a fun, but Very ExpensiveTM
, electrified Lotus on its way to creating a viable, practical, battery-powered, Everyman vehicle. Elon Musk is a man who has made me a liar multiple times, by doing what I unequivocally stated was impossible, and he impresses the hell out of me for it.
Amazon reinvented Sears, Roebuck, & Co. for the 21st
century bootstrapped off a books-by-mail business.
I'm not saying there ain't a there there. But I'm extremely unconvinced that all the there there that's claimed to be there is really there.
Swapping out the phone or fax in a laundry, food-delivery, dog-walking, or house-cleaning business is not, in the larger scheme of things, particularly disruptive. It's often not even a particularly good business when catering to the Rich and Foolish. Not that parting same from their easily-won dollars isn't perhaps a laudable venture.
The other slant of the Minimum Viable User is the one who is pushed so far up against the wall, or fenced in and the competition fenced out, that they've no option but to use your service. Until such time as you decide to drag them off the plane
. Captive-market vendor-customer relationship dynamics are typically poor.
For numerous reasons, the design considerations which go into such tools are also rarely generative. Oh: Advertising is one of those domains. Remember: Advertising breeds contempt
Each of these MVU business cases argues against
designing for the generative user. A rather common failing of market-based capitalism. Robert Nozick explains criticism of same by creatives
by the fact that "by and large, a capitalist society does not honor its intellectuals". A curious argument whose counterpoint is "capitalism is favoured by those whom it does unduly reward".
Pointing this out is useful on a number of counts. It provides a ready response to the Bullshit Argument that "the market decides". Because what becomes clear is that market forces alone
are not going to do much to encourage generative-use designs. Particularly not in a world of zero-marginal-cost products. That is: products whose marginal
costs are small (and hence: pricing leverage), but with high fixed costs. And that means that the market is going to deliver a bunch of shitty tools
Getting from Zero to One for Generative Mobile Platforms
Which suggests one of a few possible avenues out of the dilemma: a large set of generative tools have been built through non-capitalistic organisation. The Free Software / Open Source world would be a prime case in point, but it's hardly the first. Scientific research and collaboration, assembly of reference tools, dictionaries, encyclopedias. That's an option.
Though they need some sort of base around which to form and organise. And in the case of software
they need hardware
For all the evil Bill Gates unleashed upon the tech world (a fair bit of it related to the MVU and MFVU concepts themselves), he also unleashed a world of i386 chipset systems on which other software systems could be developed. Saw to it that he individually and specifically profited from every one sold, mind. But he wasn't able to restrict what ran on those boxes post-delivery.
GNU/Linux may well have needed Bill Gates. (And Gates may well have not been able to avoided creating Linux.)
There are more smartphones and Android devices today than there ever were PCs, but one area of technical advance over the decades has been in locking systems down. Hard. And, well, that's a problem.
I don't think it's the only one, though.
Commodity x86 hardware had a model for the operating system capable of utilising it which already existed: Unix. Linus Torvalds may have created
Linux, but he didn't design
it as such. That template had been cut already. It was a one-to-two problem, a question of scaling out
. Which is to say it wasn't
a Zero to One problem
And yes, Peter Thiel is an evil asshat, which is why I'm pointing you specifically at where to steal his book. That's not to say he isn't an evil asshat without the occasional good idea.
I'm not sure that finding (and building) the Open Mobile Device Environment is a Zero to One problem -- Google, well, Android Inc., leveraged Linux, after all. But the design constraints are significantly different.
A standalone PC workstation is much closer to a multi-user Unix server in most regards, and particularly regards UI/UX, than is a mobile device measuring 25, or 20, or 12, or 8 cm. Or without any keyboard. Or screen. And a certain set of tools and utilities must be created.
It's not as if attempts haven't been made, but they simply keep not getting
anywhere. Maemo. FirefoxOS. Ubuntu Phone. Hell, the Psion and Palm devices weren't bad for what they did.
Pick one, guys & gals. Please.
The Mobile Applications Ecosystem is Broken There's also the question of apps, and app space, itself
. By one school of thought, a large count of available applications is a good thing. By another, it's a sign of failure of convergence. As of 2017, there are 2.5 million Google Play apps
Is it even worth the search time? Is meaningful search of the space even possible?
The question occurs: is it really in Google's interest to proliferate applications which are separate, non-integrated, split development efforts, and often simply perform tasks poorly? Why not find a way to focus that development effort to producing some truly, insanely, great apps?
The consequences are strongly reminiscent of the spyware and adware problem of desktop Windows in the early 2000s. For the same reason: competitive software development incentivises bad behaviour and poor functionality. It's the Barbarians at the Gate all over again
. With so many
independent development efforts, and such an inefficient communications channel to potential users, as well as poor revenue potential through kosher methods, the system is inherently incentivised to exceedingly user-hostile behaviour.
A valid counterargument would be to point to a set of readily-found, excellent, well-designed, well-behaved, user-centric tools fulfilling fundamental uses mentioned in my G+ post. But this isn't the case. Google's Play Store is an abject failure from a user perspective. And catering to the MVU carries a large share of the blame.
I'm not saying there should be only one
of any given application either -- some
choice is of value. Most Linux distributions will in fact offer a number of options for given functionality, both as shell or programming tools (where modular design frequently makes these drop-in replacements, down to syntax), and as GUI tools.
Whilst "freedom to fork" is a touted advantage of free software, "capacity to merge" is even more salient. Different design paths may be taken, then rejoined.
There's another line of argument about web-based interfaces. I'll skip much of that noting that the issues parallel much of the current discussion. And that the ability to use alternate app interfaces or browser site extensions is critical. Reddit and Reddit User Suite, by Andy Tuba, are prime exemplars of excellence in this regard.
Related Reading A compilation of articles reflecting this trend.
- Google Exec Says Windows 10 S Validates Chrome OS Design Philosophy:
Google VP Prabhakar Raghava said in a recent interview that the very existence of Windows 10 S is “a validation of the approach we've taken.” Raghava went on to add, “What educational institutions have demanded is simplicity. It's a real test tube for all of us, whether it's Microsoft or any of us.”... [It] is only able to install and run Universal Windows Platform (UWP) apps that are found within the Windows Store. Microsoft has locked things down so tightly that Win32 apps won’t even install....
Bootnote Yes, this is a lot of words to describe the concept generally cast as "the lowest common denominator". I'm not claiming conceptual originality, but terminological originality. Additionally:
This post was adapted from an earlier Mastodon Tootstorm.
- "Lowest common denominator" is technically inaccurate. It's greatest common denominator, but that creates a confusion as to whether what's being discussed is a high goal to be attained or a low limit which is imposed. (The LCD of any two integers is 1.)
- "Minimum viable user" plays off "minimum viable product", popular extant Silicon Valley terminology. And is technically accurate.
- Reddit fans of the concept might care to visit /DesirePaths.
Both charts start and end at 9 a.m. and 4:02 p.m., respectively. The one-minute chart provides more price bars before 9:30 a.m., but the tick chart creates more price bars during the day—when there is a higher number of transactions—essentially creating a higher "resolution" view of price moves. Currently, there are more than 400 trading platforms or brokers. This was not the case in 2008 when binary options trading started since there were about 10 trading platforms. The emergence of many brokers has been good since it has created high competition, which is beneficial to investors in terms of more bonuses and high Nadex is the premier US exchange for binary options, knock-outs, and call spreads. Sign up in as little as 5 minutes. Start trading today. Since many options are lightly traded their charts are deserts of information. Bid / ask history would be much better than nothing. Categories Advanced Topics , all , Covered Calls , Options , Options , VIX Tags fidelity Active , Fidelity Active Trader Pro , free option charts , option charts , Schwab , Schwab StreetSmart Edge , standard option ... You don’t have to be an economics expert in order to make money by trading binary options. The charts allow you to predict the future course of an asset by finding patterns in its past price movements, and after all this what we need to win a binary trade. Don't be intimidated by the charts, actually they are not that hard to read and understand.
1 hour binary options strategy 24option /stockpair 30 Minutes Binary Options Strategy 24option /Stock-pair Best broker for strategyhttp://binaryoptionsteacha... Traders utilizing a longer-term approach while trading options can look to use the weekly chart to grade trends, and the daily binary options trading chart to enter into positions. Learn How to Read Charts - On EU we see a clear level of support on the Weekly TF for about 11 weeks. On the H4 we saw a clear break of structure and complete 110% retracement. Many would have ... i will show the best trading strategy Are binary options a good idea? If you're thinking about trading binary options, watch this video first. Check out our FREE training for traders https://bi...