Ideas for Computing
github.com
github.com
Maybe we need more forwarding-reaching fiction in our world. More essays on computing futurology, grand envisioning of what we can achieve with software. Even ambitious prototypes of a new way to do something (like Lighttable)
A lot of what I see are tooling details, lot of boring effort duplication on mostly-identical languages and lot of nitpicking/bikeshedding comments like: well, you may have a good idea for solving world cancer, but your article does not work in my weird mobile browser, so your credibility is shot.
Where's our version of "The Mother of all Demos" ?
Software patents are another hindrance to innovation too. Often the results of some publicly funded research are patented, and never actually made into end products, and the public has no rights to use the invention funded with their tax money. I'd bet a dozen or more of those hundred ideas are already covered in part by some patents that aren't used in any real products, but serve only to prevent anyone else from developing them.
I can't really see most people being so open about ideas as the author of this article precisely because innovative ideas people have will also come with the idea of monetizing it, with the belief that they need a patent to do so.
What's more of a shame, is a list like this 100 ideas, doesn't serve to prevent anyone from patenting an implementation of such idea, despite it already being published. Articles like these do not serve as 'prior art' when considering patent applications.
Perhaps it wouldn't be so bad if anyone who developed an idea could patent it, but little guys, hobbyists and academics can't afford to without outside funding, whilst the wealthy corporations whose primary motive is profit can patent ideas by the dozen.
etc. etc. etc...
If everyone monetized everything our industry would collapse.
It's a balance. Innovation and monetization are different beasts. Some ideas are so awesome they just have to be shared. Techies are smart enough to think bigger if they really wanted and make computing better. I hope my example sets a precedent.
Sharing your idea may make technology better than if you kept it secret.
I put many of my own ideas out there, usually in discussion threads though, as I'm not a blogger. There's some overlap between ideas I've had myself and your own ideas, such as the package-manager for package-managers, I've discussed several times and experimented with implementation. It just demonstrates further that ideas that are ready for introduction aren't "inventions" at all: they're inevitable next stages of the evolution of ideas. Yet someone who has the money can claim they invented it, and use the legal system to prevent everyone else using it.
I can't picture how we could create such system in a society built around the complete opposite, where the government backs corporations and fails to acknowledge the innovations of individuals, unless they pay for it.
On a side note, I have many ideas that I've not released, not because I'm worried about someone stealing them, but because they're so far outside any mainstream convention that I'd be seen as a raving lunatic by many if I published them.
This is a very good reason for why your idea should be put up for everyone to see. No, I don't mean that they should think you're a lunatic, but because of how awesome it would be if someone just picks up the tiniest bit and develops it.
Today? :) If they are really that crazy, this alone is the reason to release them into the wild... and you will feel better to. Ideas are only alive when they are free (as in released) ;p
Any feedback would be appreciated!
Certainly without such restriction the great minds of the world would be free to ponder the future of human-computer interaction and solve real problems. I am vastly underwhelmed at the state of technology in the year 2013.
We had an idea a few months back for a product we wanted to exist, talked to some other people that also wanted it, built it (total cost ~$120 and lots of free time), got some people to use it, and one of the first thing several of them said is "I wish I could pay a few dollars to do X". We hadn't thought of that.
The point is, we could have said, no there's no point in doing this, the only clear monetization path for us is worth less than the cost in hosting, and killed the idea in January. However, we decided that lots of people would probably use it if it were free, so we built it, and it turns out that we would be able to make it profitable by testing it.
That is an absolute silly notion. Money is a token of value, so if you're creating value for someone, it shouldn't be too hard to get some money for it.
Examples: The Internet, while initially a public research project, did not take off until it was commercialized. Personal computers and mobile phones - completely transformational technologies, the innovations of which went hand-in-hand with making tons of money. Google and Apple both innovates like crazy and they're two of the most valuable companies on the planet because of it. Much of the best open source software projects are off-shoots of commercial ventures.
Douglas Engelbart and his team innovated, originated and practically invented all of modern computing paradigms and interactions. Engelbert died unable to garner interest in his grander vision of accelerative bootstrapping. I suspect he saw modern incarnations as bizarro implementations, outwardly similar imitations apart in spirit. Those like Bret Victor recognize that spirit. This list shows some of that spirit. I would argue RapGenius qualifies too. Here's hoping this picks up as a trend.
Google and Apple both innovates like crazy
I would dispute that Google and Apple innovate like crazy. They do more polishing and acquiring, with most of the innovative work in service of the product, a benefit but not a new paradigm. Voice recognition, self driving cars, heads up displays, multi-touch,internet blimps. For the dozens of researchers who devoted decades of their lives to this work, the recognition Google and Apple get for things on like that list is bittersweet.
This is not to dispute the tremendous innovative thinking and work it takes to package research to a public ready state, I am merely pointing out that true bellwether innovations (2) often go disproportionately unrewarded.
(1) With a negative income tax and library->hackerspaces, that would very often be perfectly ok. Such people are moved more by vision than by monetary rewards.
(2) Which will themselves be combinations of existing things, the key is they should be the first to inspire with this combination, even if in very rough form. By this definition pagerank and the iphone are the key innovations of Google and Apple.
The statement, "Money is a token of value, so if you're creating value for someone, it shouldn't be too hard to get some money for it," is ideological and doesn't withstand scrutiny. For example, a mansion would represent enormous value for someone in abject poverty, but they may have no serious ability to compensate you. (This is why we may have bizarre outcomes like roughly as many homeless people as empty hotel rooms and apartments. The allocation system is profoundly irrational.)
Also, there are no outlets for promoting, discussing or finding projects like the ones described here. And, if that's not enough, integrating anything conceptually new with existing infrastructure is usually a royal pain.
Regardless, these are good ideas.
Firstly, a patent doesn't cover only an abstract idea, but an abstract implementation of an idea. It's a description with a list of claims about how the idea is acheived, which can cite prior art, but the requirement is that a "non-obvious" invention occurs in the claims, which can unfortunately include "combination" of two or more existing ideas.
Given that the author had only described brief ideas, they might serve as prior art, but as they don't really establish claims on what is invented, someone could later come along and take the idea and develop it, coming up with "inventions" in their implementation. Such inventions are probably obvious to someone who takes the time to develop an idea, and would be rediscovered by anyone who starts from the same piece of prior art. A problem is that patent applications always start by using the broadest sense of the "invention" that it covers, and the claims are narrowed down if the application is rejected by the patent office, but applications can be revised and resubmitted many times.
The obviousness of ideas really depends on how much consideration is given to each one, so perhaps it would be in the interest of authors to establish claims on how each of their ideas might be achieved, as patents do (although they shouldn't need to be written in legalese.) Maybe a separate hyperlinked article where more detail is given on each, particularly the ones he cares most about, would surely improve the protection against the ideas being taken.
One of my concerns is the invention of new terms in patent applications which cover already existing ideas. I've seen patents which cover something very obvious, but choose some unknown term to describe it like it's something new.
The other major issue with these ideas is whether they are discoverable by a patent examiner, and proving that they were published prior to a patent application.
I had a discussion with a patent examiner a few years ago, and he pretty much expressed that existing patents, journals and scientific publications are preferred as prior art, because they are easier to verify. Other non-patent literature is googled, and archive.org is sometimes used to confirm publication date, but is unreliable.
However, I've just been reading the manual on patent examination[1] and it turns out that the scope of online publications is quite broad, and that providing a date on the publication is sufficient for an examiner to consider it prior art. They also need to archive a search strategy for each application.
I guess what we can take from that, is to ensure that we always include a publication date, and make an effort to reasonably disseminate the ideas so that they can be easily found by examiners and used as evidence that it was accessible to any patent applicant. Guess that means I should drop a self-hosted wiki and publish on github like the author too.
Bret Victor, who has been inspired[1] by Doug Engelbart, has showcased plenty of innovations on his presentations/writtings:
* Magic Ink[2]
* Stop Drawing Dead Fish[3]
* Drawing Dynamic Visualizations[4]
* Media for Thinking the Unthinkable[5]
* LearnableProgramming[6]
* Inventing on Principle[7]
[1] http://worrydream.com/Engelbart/
[2] http://worrydream.com/#!/MagicInk
[4] Drawing Dynamic Visualizations
One I had:
Bash scripting in the style of hypercard.
Hypercard was described to me as a system that had a set of functions and let the user make programs out of them. Bash syntax is simple enough that making an interface that gives you the power of shell without degenerating from the original should be possible. The output should be a regular text based bash script, allowing others to edit without the program and the user to see what's going on underneath.
EDIT: A second idea to go with the first:
A utility that allows you to create a GUI window from the command line. This could be used in conjunction with the Bash script editor to make graphical programs that the user can easily incorporate into their (presumably window based) workflow.
Defunct now, but it lets you easily create windows without all that event-basedness that is annoying and unfit for scripts: http://easygui.sourceforge.net/
In Gnome there is Zenity (https://help.gnome.org/users/zenity/stable/) that allows creating simple dialogs from command line.
It sounds like the Clojure library Stevedore [1] does what you're looking for there.
But yeah; maybe LightTable + Stevedore could get you halfway there...
This feels like what Automator is. It's definitely not as powerful as Hypercard was, but just for shell stuff its very cool. Not text based, but it can help accomplish A LOT of bulk processes.
See PowerShell with ShowUI, on Windows.
Edit: or Apples MPW shell back in the late 80s had a posixy set of command line tools that came with a shell called "commando". When invoked, it presented a dialog of all the tools options and constructed the command line from your choices. Kind if like training wheels, and it was smart enough to disable conflicting options, or to prompt for paths as appropriate. It showed the command syntax being built up. Eventually, I think it made its way to a/ux in 1992 or so.
I would like to point out a general theme though. A lot of these ideas seem most relevant to technical savvy people and I think why a lot of them (especially UI stuff) have not been implemented is because interfaces must cater to everybody.
Perhaps what we need more of is a dev mode switch (s/w or h/w) like the Chromebook has which enables a lot of these ideas so that the ordinary user is not overwhelmed.
Some of the ideas in the list are aimed at a general audience though. So perhaps each entry in the list needs to make a note of who the target audience is.
Many show a lack of vision, why are we thinking about putting buttons and windows all over the place, adding complex nonstandard headers willy-nilly to our emails when we could be thinking about important things like indexing the vast power of existing UNIX tools in a voice-controlled environment?
Ideally this would have a fast radio, so I could just leave it in my bag while I'm walking around listening to music on my phone; and a high-speed physical connection so I can plug it in if necessary.
I don't understand very well how would you like to implement the "93 Shell Output Pinning". Usually I do that with an array variable.
http://www.storytellersoftware.com
It allows one to comment on the evolution of code rather than on individual sections of it. Currently, there is not a good place to write down why things have evolved the way they did. There is a search/filtering interface to find only the interesting bits of history.
simple NLP solution
famous last words.That said, I wish there was a site that connected people with complementary skill sets around similar product ideas.
I agree with your idea (#3) but only as the reverse -- imagine a website of "ideas" and mockups waiting for people to implement them. I believe great apps start with design, not with a backend. (Of course you can write them in either order -- the point is to have considered and drafted a design before starting on the backend).
I also keep a spreadsheet of ideas that I'm probably never going to work on, this might have inspired me to publish my own list.
Also, if anyone is interested, Reqqi is hiring
I'm currently working on something that superficially looks like #4, but includes at least 20% (potentially more) of these ideas (or make them obsolete).
Most of them are trivial, and I'm sure much of us didn't get anything new from this list. Heck, I could come up with 50 more just like that (but maybe not that related to programming).
Also, you spelled "Coalescing" wrong :)
Do you know if it has an API? It would be nice if it was a standard piece of architecture available on the desktop environment without creating completely dedicated dialogs. There would be some way to define how interfaces are to be merged.
It doesn't convert between long and short options or sort arguments but it does help you by offering the completion which means less typing and slightly less memorization.
Here's what my autocompletion looks like: http://leukensis.org/files/zsh-autocomplete.png
The program has to provide its autocomplete files, but it's very powerful. My 'kill' autocompletes with a ps-like output, for example.
And, say, a live browsing view of folders as you autocomplete a path.
[note] the biggest one for me is the "life engine" - I would happily pay you £50/month for this!
Anyone to join hands with me?
I don't quite know how but these will have to go on the occasional tinkering list.
I have probably as many half-baked schemes in the back of my mind. We probably all do. Why is this list particularly interesting?
Heck, lots of these ideas sound downright bad. Adding operations for "put in new folder" and "pull out of folder"? Don't we already have plenty of ways to do this? A basic set of primitives (create new folder, move files to folder, whether done through the UI or on the command line), allows you to compose those simple actions into the more complex ones, rather than having some giant menu of everything you could ever possibly want to do with files that you need to navigate through.
I'm just not sure what the value of long lists of vague, half-baked features ideas for random software is. Why not actually build one or two of these? That would be far more interesting.