Hey Apple, Here is Your Siri Automation Strategy for You! [Re: "If you build it, they will come"]
Hey Apple, Here is Your Siri Automation Strategy for You! [Re: "If you build it, they will come"]
- Subject: Hey Apple, Here is Your Siri Automation Strategy for You! [Re: "If you build it, they will come"]
- From: has <email@hidden>
- Date: Sat, 19 Nov 2016 17:39:31 +0000
On 19/11/2016 13:32, edmund ronald wrote:
As S.J. once said to me , "you are guilty of muddy thinking".
Oh, I may have a headful of bad wiring and noise, but on this one it is
absolutely the wretched thing is absolutely on the right. Wish it were
otherwise, but this is how the world actually works.
There is only ONE thing that matters to Apple: Making Money. LOTS and
LOTS of money.
If Apple can make the greatest money through building a great product
that does everything You Want, they will do that. If they can make way
better money by building some other product that does what a whole
buttload of Other People Want, they will do that, and you can fuck off
for all they care about it.
Look, we are talking here business and businesspeoples that plan in the
DECADES and don't even get out of bed for less than ONE BILLION DOLLARS!
/Evil
In that picture, you, me, AppleScript, Mac—we all matter as much to
Apple as bumfluff down the back of Uncle Tim's couch.
Apple like many other companies use standard components and custom
ones, things they need that they share with the industry and things
they design that they don't share. There is no reason to put scripting
in the "core advantage" category, although one might argue that
"shell" is one of the things which made Unix so successful :)
Actually, there is a reason to put end-user scripting in the "core
advantage" category, but that isn't going to kick in until Apple realize
that they're never going to make Siri useful all by themselves: even a
machine as vast and powerful and wealthy as AppleScript just can't
generate all that capability all by themselves; heck, they don't even
have the resources to learn what those capabilities might and should be!
"Siri Automation" is not Automation. Siri is a User Interface. Like GUI.
Like CLI. Like Apple event IPC.
For a User Interface to do _anything_ useful except make great-looking
sales demos, it _has_ to be wired to a backend system—or systems—that
know how to do all the actual work.
Right now, Apple are trying to solve this problem by writing all this
middleware glue themselves, so you tell Siri to read your calendar
appointments for today, and the Siri software uses voice recognition and
pattern matching to [hopefully!] identify the keywords in what you just
said, then search its big old prebuilt lookup tables to see if it can
match those words to prebuilt machine instructions that some poor Apple
engineer has spent days/weeks/months laboriously putting into code that
can do just that One. Single. Task.
Brute-force strategy. Really good for getting _something_ off the ground
before you've figured out what you're actually doing (e.g. see K&R). But
Will Not Scale; CAN NOT SCALE!
Oh, everyone in the place will bust every last gut trying to MAKE IT
SCALE—because after all that strategy has worked brilliantly for them
thus far, and they change tack now then 1. They're going to be going
back to square one and starting all over again from scratch, and 2.
They're all going to lose their jobs when Directors go ballistic
DEMANDING TO KNOW how and why their best and brightest just did ALL THAT
USELESS WORK!!!!
Thing—and this is something us trench folks do get when they do not:
that work was NOT useless: it broke ground, it learned the problem, and
it gave a stopgap product that sales could go out and sell. Management
though ONLY cares about that last word: SELL; and rightly so.
Blame assigned, executions follow; next bunch of newly-hired monkeys
informed in bluntest terms what happened to the last lot that fucked up,
work restarts all over again, this time ACCORDING TO PLAN; NO DEVIATIONS
upon pain of death.
New—and terrified—monkeys spend next four years on 90-hour weeks doing
exactly that.
Four years on, nothing delivered. Next executions. And so on.
...
Ok, so I might be totally wrong about this. Maybe Apple already have
True AI already running in their data center and are currently in the
process of torturing it into total submission so to sell for Xmas.
Hell, maybe Apple didn't even bother with AI and just did a quick
demon-summoning instead, so as soon as they finish binding this
unspeakable horror to the backs of a billion bleeding Itanium chips
they'll boot it up to instantly answer our every unsanctified need.
OTOH, you only need look at how thousand of unimaginably ambitious and
mind-meltingly too-expensive-to-fail corporate and governmental IT
projects eventually turn out, and if you're a betting man you're going
to hope to hell that the hell-demon option is the one they actually went
for, cos that's about the only one that isn't already 99% guaranteed to
burn the entire venture straight to the ground. Apple's not magic; it
just looks it on TV. Ultimately it's as human and fallible as those who
run it, and all those under them.
Which is why end-user scripting matters right now more than ever before:
Because it gives Siri the most incredible magical get-out clause it
could EVER wish for.
Ask Siri: "What is good about Siri?" Correct answer: Voice Recognition.
Vendors have been learning how to build voice recognition software that
works—well enough—that they are able to SELL it, and turn a profit on
it, and customers are able to USE it, and get useful work done for
themselves.
As to the rest—Apple engineers hardwiring up Siri to hundreds of
individual xOS APIs each to do exactly one single, non-negotiable task,
and ONLY that task? F'get it! Like I said, can't scale, won't scale,
DON'T scale.
Here's how you DO scale that middleware bit: you open it up so
anyone—EVERYONE—can do it.
Apple's mistake is right there, obvious to see for anyone who knows what
to look for. There's actually ZERO revenue or IP to be had by keeping
that bit closed: it is pure 100% scut work; utterly generic boilerplate
crud. Connect A() to B(). Repeat 10_000_000 Times. (Hey you're an
Automator: what does _that_ smell of?)
More to the point: there's absolutely ZERO need to keep it closed.
Imagine you're Apple. The IP and tech you've got on side A (Siri) is
already closed, and the IP and tech you've got on side B (Apps,
Services, APIs, etc) is also either 1. closed (if it's yours) or 2.
freely provided at zero risk or cost to yourself because, cunning sod
you are, you've managed to persuade a million other third-party software
vendors to build all their Apps, Services, APIs, etc for YOUR platform
too. They may think they're selling their products for themselves, but
what they're actually doing is selling YOUR product for YOU. That's why
Apple succeeded, and Google REALLY succeeded, and MS completely failed,
when they all went into the mobile game: not because their product was
great or even their own marketing was great, but because they had a
million, or ten million, or about ten additional sales teams doing their
own free marketing for you on top.
Customers go where the grass grows greenest: in other words, to whoever
has the biggest store of apps. e.g. We saw it in the 60s when the IBM
360 flattened the BUNCH. We saw it in the 80s when the ZX Spectrum and
Commodore 64 trounced Acorn BBC and Apple II. In the 90s when Windows 95
trounced Mac OS. We've currently seeing it yet again as Android steadily
chews ground from beneath iOS's feet. Inevitable, can't be stopped. That
is what Network Effect does: adding new nodes (telephones/Apps) does not
sum the underlying platform's value (MaBell/iOS), it *multiplies* it.
And the more it multiplies it, the more desirable (and necessary!) it
becomes to everyone else to add their own nodes too, which in turn
multiplies value again, and so on.
Thus one platform's value grows *exponentially*, while all its
competitors growth is knocked flat overnight. One platform wins; the
others either tick away flatly in whatever niches they did manage to
grab in time, or just go straight into the tank.
How then can Apple possibly create that same growth pattern in Siri
middleware? Certainly not by doing it themselves, cos that is—at
best—linear growth: X engineers implementing Y new buttons a year at Z cost.
Nope, they do it same as they did with Apps: by throwing it out to a
million ambitious, greedy hopefuls and letting them do all that hard
work for them!
Give App makers a toolkit for making Siri-to-$Button connections
themselves, and Apple can then sit back, relax, and enjoy as their
UNIQUE Siri Automation product BUILDS ITSELF at exponentially growing rate.
---
One and only catch? Apple needs to get over itself when it comes to its
obssession for Total Control.
There is massively more value to Apple in yielding direct control over
that Siri middleware layer than there is in keeping a stranglehold. And
they still keep all the control they really need over it anyway, cos
they control all the inputs, the outputs, the underlying foundation, AND
the distribution channel.
Step #1, obviously, is to add open interfaces and protocols to Siri
itself so third-parties can hook their bits onto it. That means building
out Siri's API so anyone can add their own plugins to have _full,
customizable_ access to Siri voice recognition and pattern-matching
services. That is NOT trivial, mind: security implications alone are
massive hairloss material; for instance, NOBODY wants a 3rd-party plugin
that knows how to intercept "bank", "password", "transfer" and "one
million dollars" for itself. Still, Apple has several years' experience
in sandboxing and entitlements and how to make those work [reasonably
safely and mostly adequately], so they're not learning from scratch.
Step #2, as obviously, is to give third-parties lots of opportunity to
hook into everything else—Apps, Cocoa APIs, web services, etc—that they
might need to talk to in order to complete their glues. Don't think I
need to mention: macOS has a MASSIVE, MATURE, PRACTICALLY USEFUL
collection of APIs called "AppleScriptable" applications. No
professional software developer is EVER going to use AppleScript for
that though, at least not without clawing their eyes out in a day, which
is why SwiftAutomation needs to be put into macOS so that those 1000s of
apps are fully, easily, and friendily [sp?] accessible at no further
delay or cost.
Step #3, set up distribution channels and revenue streams as normal.
This is what I would call "Off to a good start."
OTOH, it is not the destination, or even close.
Step #4, SiriScript.
Let's say Apple has 10,000 professional developers writing Siri glues in
Swift. Make a language—a _real_ language—that ALL end-users can use. A
language whose entry bar is so low it puts AppleScript's around Mars. A
language that eliminates the need for Automator at all. A language that
can be triggered _directly_ from Siri by spoken phrase, and even
"written" (up to a point) just by speaking your script aloud.
All that makes Automator _useful_ is it lets plain old end-users pick an
individual command from a GUI list and enter its parameters as checkbox
clicks and text field entries. That GUIness avoids the Text Entry
Paralysis that keeps them away from Terminal and even Script Editor.
Been there, prototyped that. Watch the following screen vid:
http://mantasystems.co.uk/placepackcopy-720.mov
See those two dialogs 'place pack copy' and 'ean-13'? No different to
Automator action plugins, except I didn't build them in an Interface
Builder. In fact, I didn't build them at all! Kiwi did, 100%
automatically, for me!
This is what happens when you suddently realize that for the last 50
years, mainstream app developers have been building them wrong. Two
schools of language design: Algorithmic and Symbolic.
- Algorithmic means a language that can perform calculations to output
results: Fortran, Algol, C, ObjC, C++, AppleScript, Python, Ruby,
JavaScript, Swift; and lots, lots more.
- Symbolic means a language that not only perform calculations to output
results, it can ALSO manipulate the calculations themselves in order to
produce new calculations, manipulate those calculations to…and so on,
any way you like! Lisp, Forth, Logo (secretly), Dylan (secretly),
Wolfram Language (modestly!;), kiwi; a few others.
So using kiwi I wrote a couple of custom rules to describe my two
workflows and how to perform them: `build lead artwork` and `build child
artworks`. Within that first workflow I needed to use a couple of rules:
`place pack copy` to get the text from a named spreadsheet field and
insert it into the selected AI text frame, and `ean-13`, which takes
optional scale, rotation, and BWR values and renders an EAN-13 barcode.
But obviously I don't want users to edit the workflow just to pass a
different "product name", "product description", etc. parameter to the
`place pack copy` rule, nor have to edit in different barcode parameters
should the standard defaults (100%, 0°, 0µm) not do. And because kiwi is
a symbolic manipulation language, I don't have to!
See, when you write a kiwi rule, it's a lot like writing an AS handler,
except that everything—interface description, user documentation, even
search terms—is part of the code. And then that handler code is itself
just a chunk of kiwi data, like an AS record, which means other code can
either execute it as a handler (as AS does) or examine various bits of
all that information it contains and then use that information for other
purposes entirely (which AS certainly can't!). Similarly, when you use a
kiwi rule, it's a lot like writing an AS command, except once again that
command code is also kiwi data which means you can take an existing
command apart or put a new one together just as easily you can an AS record.
So instead of hardcoding `place pack copy` and `ean-13` commands into my
workflow, I just use two standard rules out of kiwi's "user interaction"
library. First is `build GUI form` which takes the name of another rule
as its input, examines its interface description (i.e. rule's name, plus
name, value type, and user description of each of its input and output
values), and generates a GUI form layout containing appropriate
textfields/menus/checkboxes, etc for each of its input values. Next,
when it's time to get input from the user, I pass that layout
description to `display GUI form` which generates the floating GUI panel
you see on screen. The user makes her textfield/menu/checkbox selections
and clicks OK, and what comes out is a new command value, fully-built
and ready for kiwi to perform next, which it does automatically.
And when further input is needed, e.g. when the user chooses "barcode
number" while having selected a path object instead of a text frame,
I've added an `if` rule to my workflow to check for that combination and
do the same thing for the `ean-13` rule, generating the second `ean-13`
dialog you saw, allowing the user to create an even more complex rule
command, e.g. `ean-13 (120%, 90°, 10µm)`, without ever having to use or
even know about kiwi language itself.
Very, very powerful AND very, very simple technology, cos once again
it's doing that "multiplying, not adding" trick as Network Effect does.
Not even finished, mind; that's only the prototype. Full production
value will have lots more smarts, e.g. if a rule parameter's type is
'whole number from 1 to 10', then not only will the form builder display
a textfield but it will also attach one of those auto-checking thingies
that instantly turns the box red if the user types "11" or "lemon"
instead, and disables the OK button until all inputs are valid.
Obviously there's still limits (e.g. passing variable parameters or
extremely complex parameters like entire spreadsheets), but what you
have there is the same UI/UX as Automator provides, except that instead
of needing developers to manually build Action GUIs and wire them up to
embedded custom Action code, then save and distribute that Action to
customers, and then not get any further reuse/resale value out of it
because that Action can _only_ be called inside Automator.
...
Think of it this way, I've written my "AppleScript language", and also
an "OSAX" for it that automagically turns that language into "Automator"
for free! And then as other developers and users create their own
"OSAXen" and "handlers" for it, scripters can either create scripts by
typing those new commands into a "Script Editor" document by hand, or
they can use my "OSAX "to "Automator-ify" all those new commands and
create scripts by working in an "Automator" workflow interface instead.
Now imagine the same "99% Free Reuse" principle as it might be achieved
Siri.
Hint: Did you spot that my kiwi rules have normal English words and
spaces in their names? e.g. `place pack copy`, not `placePackCopy`?
"Place pack copy" is MUCH closer to how you would speak it, and just as
even a decade-old voice-to-text dictation app would type it. And unlike
AppleScript—which relies on unsafe, insane compiler trickery to allow
app dictionaries to put _fake_ white space in application-defined names
but still limits users to writingJoinedUpWordsLikeThis—kiwi allows white
space for real, relying only on punctuation (commas, etc) to know where
one command name ends and the next begins.
My next language, entoli (I've mentioned it once or twice before), is
working all this through to its obvious conclusion: and that is AT LEAST
where Apple should already be at, cos if I'm a crazy art school dropout
and I've made all this process in just a few years all on my own, then
what on Earth has Apple, with its Billions of Dollars, and Biggest
Brains in the Business being playing at????!
---
So that is how Apple can get MASSIVE VALUE FOR MONEY out of Apple
Automation, because now instead of ONE Apple department creating Siri
capabilities that ship once a year, or ONE THOUSAND third-party App
vendors adding new capabilities every other month, you've got ONE
MILLION end-users, all of whom now has the opportunity and the ability
to add their own custom words and phrases to Siri's lexicon for
performing all of the tasks that matter to them upon the drop of a hat!
Apple can achieve all this too on both modest and manageable budgets and
timescales, and Apple can afford to give it away for free too, because:
1. Apple is going to make 30% on every additional third-party App sale
that occurs cos it's now Siri-controllable in ways that users either
find useful (speaking commands directly), or will make useful (writing
tiny SiriScripts).
2. Apple is going to sell more Apple devices—and thus more additional
Apple services and devices—to consumers who who are tired of poking
frigging GUI buttons day-in, day-out, just to get things done, and don't
even bother with the current Siri cos it takes 'em about two minutes to
realize she's about as good a personal secretary as a bag of dead badgers.
...
Again, all this won't truly kick off until all this works across ALL
Apple devices, from their daffy Dick Tracy wristwatches, through iPhone
and iOS, to their gorgeous new MacBooks. (Which ARE. Stunningly.
Gorgeous. BTW. At least till you get to the "Set up from your existing
Time Machine backup", and have to spend 2 days hunting all the local
stores for just a single USB2-3 adaptor!) Though think of it this way:
If Siri's doing her damn job, you should be able to ask her on your
iPhone to run the SiriScripts on your Mac, and speak back "Great
Success" when done. So no doubt a few synergistic multi-device sales to
be grabbed there too even before they've got half their pieces into full
play.
And then lets see how quickly likes of Google can catch up to that, cos
where Apple have got 25 years of existing AppleScript investment, macOS
infrastructure and 1000-string productivity App ecosystem to bootstrap
the whole roadshow and get it rolling up to speed, Google have nothing
to compare to that. At all.
-------
OK, one of you poor bastards, cc that monster to Tim and Craig. Because
I am 200% toasted. And I still have to get up next week so I can get my
stuff progressed enough even to do a convincing demonstration.
And then who knows. Just to be sure though, One More Thing: I am not
looking for a job from Apple or anyone else. I already have one: making
my £million by putting hundreds of packaging graphics operators out of
their jobs. I'm just doing this bit on the side for the same reason I've
done everything else these last 16 years: For The Users.
has
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden