The end of apps, and why UX designers should care about type theory (2013)
pchiusano.blogspot.com
pchiusano.blogspot.com
There seem to be 2 major friction points that prevent one application to be used by another or being a part of a flow:
1) Generating an API
2) Consuming an API
If there was a way to automate API generation based on parameters then presumably a person could create an API endpoint that gets them the data they want and then use that in an IFTTT recipe.
However to use it in an IFTTT recipe the API should also have a specification generated to we can automate a program like IFTTT to look at the specification and create the API consuming code.
So from a simplistic viewpoint it would be better to think of how to create a standardized way to auto generate APIs.
Generates code from parameters (types). If parameters form a function, then code will implement it. If function final type is IO a, then implementation code will be side-effecting action.
And, having a function f for a type T, you can ask for a function g that will call f, giving you a type Q. I guess that would stand for "Consuming API".
I have over 100 different apps on my phone, and that number only keeps growing. It seems like there's a new app for everything nowadays. You'll soon (if not already) have an app for your car, your door lock, your fridge, your fan and your shoes. How is a person supposed to navigate all of these apps and get the most of it's environment when drowned in that uncalled-for diversity?
I probably have created over 1000 online accounts, and I don't see that slowing down either. The lack of communication between apps makes it very difficult for new players to receive any significant contribution from their users. Why would I invest in a platform/service that can disappear the next day and force me to start over? The semantic web seems to provide a quite elegant solution to this problem.
It seems to me that we're only going to overcome this problem once we stop designing UI by hand. Once we shift our focus away from guiding the user experience, and put the effort toward improving the semantics of the data, will the generalizations of UI emerge and unify all experiences under one language.
We could assign each app a name, and design a universal app launcher that, given a name, would navigate to that app, launch it, and execute it a safe sandbox for the user. As a bonus, now any app in this universal app launcher could link to other apps, so that apps could launch other apps as necessary. That way, the complexity of keeping track of apps isn't up to the user, but instead each app presents links that allow the user to navigate to other apps as necessary to get their work done. Since apps would be connected to each other in a mesh, or web, and this launcher would allow the user to browse all of these apps, we could call this universal launcher a web browser ;)
EDIT: More seriously, this is exactly the problem that URLs (Uniform Resource Locators) are supposed to solve.
My point is to get rid of apps (and websites), not make it possible to have more.
Being nit picky but:
> I still can't get Gmail to do even simple tasks like schedule an email to be sent later or batch up all incoming emails containing a certain phrase into a weekly digest!
You can do the latter with labels in gmail.
There is a fair amount of accidental complexity with programming, but there is even more inherent complexity. Thinking about problems using strict formal logic is hard. It's not something that everyone has the time, patience or inclination to do. I am 100% in Bob's camp in that argument; I think it's utterly and completely unrealistic to expect the average person to know how to patch together APIs in order to deliver functionality. Moreover, I don't even think it's a bad thing. Most people call a plumber when their pipe springs a leak. Most people call a mechanic when their car starts spewing smoke. I think it's fair that most people would call a programmer when they need an application made.
It's called Excel.
Yes, people use Excel to make complex applications. But it's the same as people jerry-rigging their own wiring, or attempting to use heavy machinery without the proper qualifications. It can work, but a lot of the time, it leads to collapse, disaster, and thousands of dollars in damage.
At this point it's clear that the average programmer, let alone the average user, actually likes getting paid to write mindless glue code and copy data from one spreadsheet cell to another. I've been teaching physics and maths for years, long enough to learn that normal people have a strong aversion to the sort of abstract thinking that these systems demand of them.
Agreed. This is the point I was trying to make, but I think you said it better than I did.
Visual Basic 6 is the exception to your list. A LOT of laypeople used VB6 to create really useful programs. It is hard for people who weren't alive then to understand just how gigantic VB6 was (partially because VB6 predates the web).
Unfortunately, Microsoft killed VB6 with the transition to VB.net.
So why not be hopeful that the modern laziness of the human who wishes to scroll through a twitter stream of Facebook feed slowly dissolves and is replaced by people who wish to make computation more useful to them? More personal to their needs, and more able to help them accomplish their goals of obtaining amd organizing knowledge and their life?
I agree with the premise, not that, currently, all of us are ready for such an implementation. It'll require a reboot of our education system, and what we think is important to teach in schools.
> Most people call a mechanic when their car starts spewing smoke. I think it's fair that most people would call a programmer when they need an application made.
The major difference between the mechanics world and programmers world is that one is 100% symbolic, the parts are (potentially) free, reusable, and non-degradable. Given someone knows functional math, and is provided with these free, reusable and non degradable parts, surely, itd be a much easier task than learning everything about cars and the ways they can fail.
This futuristic building block programming world still maintains professional programmers who create abstractions that are easily composed. After all, thats the hard part, right? (Beyond scaling and centralizing, which as the article points out, may be a problem caused by the need for centralization in the first place)
> I think it's utterly and completely unrealistic to expect the average person to know how to patch together APIs in order to deliver functionality.
I feel like you are making this sound harder than it really is. Again, its the easiest part of programming, and yes non programmers dont know how to do it, but is it any different (or difficult) than forcing or suggesting them to learn calculus (or pre-calculus) in high school?
[1] http://blog.databigbang.com/ideas-egont-a-web-orchestration-...
It is very much just targeted at my own use. I'm not doing a lot to make it work well for other people, or non-programmers. But I still think it's an interesting technique that people here might like.
https://github.com/traverseda/rethink-tools
Python provides a way to import whatever functions calls.
Rethinkdb provides a generic data store. I can add fields (keys) to objects (rows) as needed. This is somewhat analogous to pythons duck-typing.
It has excellent network transparency. I'll soon by trying to get a rethinkdb server running on my phone, so I can load text messages into it.
I can also do basic queries across my data.
We'll see how it goes.
Through the lens of a developer, sure. As a consumer / user, you likely appreciate the simplicity this affords. Similarly, if you are a car enthusiast, you'd shudder at the thought of bringing your car to a Jiffy Lube for an oil change when you can pop the hood and do it yourself, but the majority of car owners are thankful they don't need to get under the hood and tinker with "all that stuff".
This premise won't work for me if I have to learn a new language, new libraries and coding environments, just to implement a filter in my GMail.
Rethinkdb comes pretty close to being a generic data store for arbitrary json, and cap'n proto does pretty alright with RPC across code bases.
I'm not entirely sold on a single, global, execution environment. But python is pretty nice for that kind of work flow. You can import from wherever. Soon, you'll be able to import from remote procedure calls.
I'm not sure what's going to work, but I think it is a solvable problem. We just need to focus on reducing API friction.