ideas

a hundred ideas for computing - a record of ideas - https://samsquire.github.io/ideas/

View the Project on GitHub samsquire/ideas

One Hundred Ideas for Computing

This is a vision for how computing could be. I began writing ideas down a number of years ago - you can find the origin of many of these ideas in idea wiki - there is over 1000 pages in my idea wiki - this document though is a selection of ideas old and new. My theme is integration.

Creative Commons Licence
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Thank you to all the contributors who have been sending in examples and corrections!

1. Email Metadata

Emails could contain comprehensive metadata about the human readable content depending on the sort of email it is. This machine readable information could be interpreted to:

For example:

Potential Integrations

Existing:

2. Use Email as a Social Networking Transport

The industry lacks an open social network. A social network can be build on top of email: the user interface can be a specialised email client with email as the transport mechanism. Everybody has an email address and web frameworks can easily communicate using mail protocols.

Email can be used as a common denominator protocol. A flexible and federated social network would abstract the protocol used for communication and upgrade to a better or efficient protocol when appropriate such as realtime applications or when sharing files.

Potential Integrations

Existing:

3. Community Idea: Design This

Developers need designers to give websites viable designs. This community brings developers with complete website backends and matches them with designers to give the backend a design.

Existing:

4. Living Documents

Living documents are the idea of intra document CMS that features the insertability of arbitrary data formats and provides integrations between inserted content blocks. It’s a general purpose data structure editor. A living document is the fusion of blogs, forums, wikis, social networks and notebook software.

See my attempts to explain a living document:

Existing:

5. Life Engine

Life engine is a dashboard that attempts to collect information about your life and display relevant data on a single screen.

Existing:

6. Community Idea: Ethical Me

A tool to track the decisions of consumers to register their buying decisions in a thoughtful way.

Existing:

7. Peer to Peer Blocking

Block by default is inconvenient to users. Community driven blocking reduces risk. Configuration options should be shareable and synchronizable to increase security. The following configurations could be distributed to users who take part:

Potential Integrations:

Existing:

8. Command Auto-complete

Command auto-complete could be implemented by:

For example, if the user types grep -v, they may get an auto-complete for --invert-match. We could also provide transformations using knowledge from the index:

Existing:

Potential integrations:

9. Elements Represent Themselves

A rendering of data should stand-in and represent itself.

When data is rendered, its type information should be preserved so that the user can interact with it.

Potential Integrations:

10. The Environment has Knowledge / Context-Aware Computing

Running applications expose information on what information they can provide and what they will accept. Bring type systems up into the desktop environment. Everything - including programs, have a type and have typed parameters. A system should help you fulfil type arguments for running programs. For example:

Potential integration:

11. Representational Computing

Completing a task has a representation, such as ‘render image’ and if requested will select a program to do so depending on criteria. If the input data is in PNG format then it must pick a program representation that can render PNG. The inputs and outputs of programs are representations themselves so the type matching works upon programs themselves.

Existing:

12. The Package Manager-Package Manager

There are multiple package managers that have to be controlled with separate programs. Setting up a machine involves installing various package managers. It seems a hierarchy of package managers would permit installing any number of packages.

For example, if you were installing Publify, a blog platform:

By the end of this process, we’ve used two custom scripts and two package management systems. First the environment manager (RVM) and a language specific package manager (rubygems) and before we can even think about installing Publify with bundle. We still have not actually configured the software.

This could look something like this, where each package manager is namespaced:

mpm install script/https://get.rvm.io \
	rvm/1.9.3 \
	script/git@github.com/rubygems/rubygems/setup.rb \
	gem/rails \
	apt/mysql-server \
	apt/mysql-client \
	bundle/http://typosphere.org/stable.tgz

Existing:

Potential integrations:

13. Package Driven Development

Software complexity prohibits quick and repeatable set-ups. Software should be written to be packageable and repeatable from the beginning.

Existing:

14. Configuration Spider

Infrastructure is complicated and the relationships between hosts, paths, ports and servers create a web of complexity. Tools like Chef and Puppet help generate configuration files that programs can read. A configuration spider would allow detecting and connecting the relationships between these configuration files.

The spider would scan for configuration files, identify port numbers, paths and hostnames to insert into a graph. When the spider detects a reference to the same value, it creates an edge from both usages to the actual data. This graph then becomes a representation of system configuration, the edges link the configuration values are live and synchronized, an administrator can change the data in a single location and cause the usages to update. This could be rendered to the screen as a graph.

Existing:

15. Community Idea: Create This

This is like the Design This but in reverse. Designers create a design and a developer creates a backend for the site. Ideally suited to open source projects.

Existing:

16. “We Want This” (The Reverse Kickstarter)

A group of people want to create something but do not have the time or energy to create it. They collaboratively decide what they want and raise funding.

This is like a ‘reverse kickstarter’ or a petition.

Existing:

17. Client-side Bubble Routing

Bubble routing is an approach to detecting and handling events on the client side. Most frameworks do not use bubbling to its full potential, they create a handler for each area where an event needs to be handled and stop propagation once it has been handled. Bubble routing uses a single event handler by taking advantage of the natural structure of the DOM and bubbling. Each element the event passes through enhances the information of the request before it gets to the topmost level where the event is actually handled.

18. Shortcut Format

Keyboard shortcuts are configured differently in each program. Shortcut configuration should be in a standard format. This way you can load them and share them between operating systems and share configurations between applications.

19. Separating Frontends and Backends

Good design separates the frontend and the backend. This should be the case on the desktop too. If frontends and backends were separated, one could use the same underlying mail or instant messenger client but switch between frontends. Backends and Frontends would communicate according to some protocol.

Existing:

20. Desktop Windows and File Management Features

These are some features for file exploring programs I have always wanted. Some already exist.

When I right click a representation of a file (such as an icon or a filename), I should be able to interact with the file or folder in a many different ways:

In the detailed list view for a folder, I should be able to see the following:

From open windows, I should be able to:

Existing:

21. If you can see it, you can use it (SIUI)

This is the principle that if you can see some data on the screen, even in different window, you should be able to use it in your active program. On the command line, ‘use it’ means ‘refer to it’, such as the path of a file icon or a file path on the shell.

Take the output of git status for example:

# On branch master
# Changes to be committed:
# (use "git reset HEAD ..." to unstage)
#
# modified: file.ext
#
# Changes not staged for commit:
# (use "git add ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
#
# modified: file2.ext
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# file3.ext

If you want to refer to a file name in the above, you could type it out and use your shell’s auto-complete functionality. You could copy and paste it with the mouse or your terminal multiplexer. You should be able to refer to paths mentioned directly.

# modified: file.ext [1]

Now I should be able to refer to the 1 in some way, perhaps $m1 now stands for ‘the first modified file on the list’ which is ‘file.ext’.

Existing:

22. Shell as REPL

An invocation of a program on the terminal and its output could be interpreted as an assignment to variables in the current scope. The output of the program should be useable to the user. The developer should be able to interact with the shell or the output in a language of choice.

For example,

git status -s

Gives me the status of each file and the filename. If I want to use this data in JavaScript or in Ruby I have to parse this text manually. Ultimately the structural output of this command is this same every time. There is a list of structured data with a consistent format that could be idiomatically represented in many languages. In JavaScript this could be:

{"file": "hello.py", "status": "modified"}

The output of the Git command should be treated like an object that has already been parsed and interactions are already possible.

output.modified[0].file

This could be implemented lazily so that the effort to parse the output is not made until the user attempts to access fields.

Shell operations may be simpler as programming constructs. This way one could use the shell programmatically, in different languages.

wget http://example.com/ |  
(require '[cheshire.core :refer :all])
(require '[clj-http.client :as client])
(let [input (parse-stream (io/reader *in*))]
	(client/post "http://localhost:8383/" {
		:query-params {(input "m") (input "l")}
	} )
)

Existing:

23. Live Data

The display of data - perhaps through widgets or in documentation should be synchronized when the underlying data is updated. When something is changed in one location, all views of that information should be updated.

For example:

Existing:

24. Error to Issue Tracker Linkage

If every compiler error is automatically converted into an issue and then automatically closed when it is absent, this would give visibility to problems that were solved and which still remain. This could be integrated with a build system.

There should also be some kind of mapping between the product’s error state and a potential issue number. Currently the connection between an error condition and an issue in a tracking system is completely human - someone has to manually enter the error into an issue tracker and update the program to refer to it. Bug reporting should either be integrated into an application or interpreted by the desktop or container environment. The error state should be detectable and linked to the issue tracker.

Error copying files: drive removed. Typically caused by:

 * Unplugging drive during copy 		[I didn't unplug it]  
 * Internet connection lost				[Diagnose internet connection]

 Compiler error: undefined is not a function (line 13)  
 	> A variable on Line 13 is undefined

Potential integrations:

25. Error Heuristics

Errors have numerous causes. Once an error becomes common enough and becomes common knowledge, it may not be justified to adjust the program to provide a better error message because the error is human. Separate tools can take advantage of heuristics can provide better insight to the problem. For a compiler error, this heuristic knows where to begin its search. These tools do not necessarily need to check if the error exists, they merely provide heuristics that help narrow down the problem. For example:

Line 13: user.mailboxes()[selectedMailbox].preferences: undefined is not a function
	> `user`, `mailboxes` could be `undefined`.

Error: install is not defined
 > This was reported as fixed in version 1.3	[Open update manager / run package-manager update x]

Expected ; saw }
 > Function expressions should be followed by a ;
 > Mismatching curly brackets, counted 4 }

Existing:

26. System-wide Data interpreters

There are many data patterns that are not explicitly marked up.

Data classification algorithms can be ran against the text displayed on terminals or within graphical programs. This could be deferred until the user interacts with the information, perhaps on mouse hover or clicking on the information.

Existing:

27. Applications Expose Data Visually and Programmatically

The data that is being rendered by an application can be inspected and used as a data source for another interface. This should also be programmatically accessible.

This functionality would be user driven as to avoid performance issues. If I want to see what an application is using or doing:

Similar:

Existing:

28. Representations are Tests

A representation dictates what something is and what you can do with it. A PNG file, a JSON document, C source code or a HTML file are accepted as inputs by different applications and operations. How do we know that that applications are interoperable and compatible? Representations can be inferred by the tests that they pass. This is similar to a type inferring programming language: we can build tests that represent high level qualities about applications and data formats. These are some high level examples that reason about the outputs or characteristics of programs or representations:

If programs are representations too, they could even be interchangeable. For example, a HTTP client can execute HTTP methods taking various body data with request headers and return response headers and data. The client could be implemented in many different languages but this described interface is the same regardless of the language. If I import the ‘HTTP Client’ representation and use HTTP methods, this will result in calls to the underlying HTTP library. This would require wrappers that wrap the real library with a generic interface. Alternatively I was hoping that test cases themselves help describe the interface because test cases for libraries inevitably involve calling the libraries. For example Apache HttpClient and the connect library in node each have an interface to GET a page by URL which will probably be a string. A sufficiently structured test case may even be able to create a picture about the expected inputs, the interface and the outputs. This could even use mocking or stubbing libraries to ‘record’ calls to library functions. Essentially we want to map our subset of data and outputs to a real library.

29. Community Idea: API Competition

Libraries compete on performance and API design. The statement of the problem stays the same but can be solved in multiple ways. For example:

APIs proposed should be voted and discussed. Implementations can be attempted.

Existing:

30. Widget Servers

(see graphic)

It should be possible for design and development workflows to co-exist and to work lockstep. Modern architecture splits web applications into layers and separates data, presentation and logic. This separation is inadequate for designers. This can manifest as designs being implemented top-down into the presentation layer. Depending on the architecture, aesthetic or functional changes require development effort. A triple architecture separates and provides separate tools specialized for the following tasks:

Different people can work on the above in parallel because they are working with interfaces.

These steps happen separately and mean that page level developers should not care about the internal workings of a widget. They communicate through a standard workflow of an issue tracker and avoid introducing page-specific functionality to widgets.

Potential integrations:

31. Mounting Source Code

Sourcecode we compile or execute need not be the same as that rendered to the screen. Developers should be able to work on the same code base but view sourcecode in different ways. Mounting a source directory means we can apply bidirectional transformations between the stored sourcecode and what is opened in a text editor.

Coding style preferences can be configured on the mounted source code so that it appears according to the developer’s taste. Developers can choose indention rules and spacing settings without affecting other developers. This is is like mapping between two EditorConfig configurations automatically.

Personal preference also changes how people like to organize source code by directory. Directory structures can be equivalents:

 - src
  - models
  - controllers
  - views
 - docs

 - modules
  - users
   - controller
   - model
  - products
   - controller
   - model
 - public

Potential integrations:

32. The Built-In Enemy

Users are not informed about security issues waiting to happen unless they:

The ‘Built-In Enemy’ is a suite of heuristics that find security problems on a machine. Examples:

Existing:

33. Personal Infrastructure

Individuals lack personal infrastructure for photographs, videos, email or other services. User data is locked into assorted individual applications from vendors and service providers. A personal infrastructure is a set of machine instances or distribution of software that create a useful and serviceable infrastructure.

Personal infrastructure providers could take the same approach as business hosting or cloud providers. They sell use of the infrastructure but provide value added services.

Personal infrastructure providers should start a trend where they provide not only the front end applications or web clients but provide direct access to the backend machinery hosted in the cloud. This would cater for power users and casual users.

PI could be distributed as a virtual machine that includes:

Existing:

34. Bluetooth Friend Mesh

Modern mobile phones are powerful and possess large unutilized CPU power. The resources available to a phone such as images, videos, maps, software and cached websites should be shareable in a mesh when people get physically close to one another.

35. Edit Servers: Team Active File Visualization

People working in the same area of software can cause problems where integrating changes is difficult. Decentralised source control systems mitigate integration pain but they do not actively help prevent it. As a user enters a file, the user’s position, the following information is announced:

Users can therefore be warned when a user attempts to update something that has also been changed by someone else. For example:

This should permit multiple users editing the same file without tripping each other up.

Existing:

36. Documentation Linked Code

Documentation and wikis are prone to fall behind a code base. Creating documentation from source code or embedding documentation in the source code are approaches to keeping documentation. Documentation and code should be linked together in such a way that it is difficult for it to fall out of date.

Existing:

37. Code Overlays

Code overlays can make source code more like a document and easier to read. Source code editors make poor use of space when rendering code. For example:

someLongMethodName	(type identifier, type identifier, type identifier,
					type identifier, type identifier type identifier
					type identifier, type identifier, type identifier)

Code quality problems aside, an IDE does not necessarily need to display this exactly the way the source is. There is wasted space below the method name. An auto-indenter could align the source perfectly but this seems like catering to the plain text format of source code rather than the expressive power of a user interface.

This could be rendered like a table:

someLongMethodName

Type Argument type identifier type identifier
type identifier type identifier type identifier
type identifier type identifier type identifier
type identifier type identifier type identifier

This tabular widget would permit moving cells up and down or left and right to manipulate the ordering of the arguments list. This would update the ordering of the underlying source code without using a refactoring dialog.

38. Code as a Wiki

Code is inherently linked and related. This is similar to wikis and the nature of hyperlinks and the web.

Existing:

39. Data Trails

The data on your screen has a trail of influence. Multiple sections of code are touched before output is displayed.

Logging and exceptions can be useless in identifying errors because they do not always store all the data that was involved. A developer has to manually include the data in the logging or exception. Data trails would ensure that any request is accompanied by its parameters. This could be combined with context as an explorable web to inspect each step separately.

40. Input Services

The embeddable widgets that platforms provide should be interchangeable and interoperable. Currently the choice of widget libraries is made by application developers rather than the user.

41. Drill-down Interface

A widget represents data on the screen. It has a limited amount of space because it must co-operate with other widgets on the screen to give the entire screen meaning. Widgets are constrained horizontally and vertically. The amount of data that widgets should display depends on the current geometry. A drill down interface would allow to the user to inspect a particular facet of the interface and give it more importance, perhaps by double clicking it. This would trigger a resize of all the widgets on the screen to accommodate the user’s change of focus. This would result in widgets disappearing and others appearing.

Examples:

An email client shows a panel of folders, an email preview pane and a detailed table of emails

 - Drilling down into the preview pane would make it much larger and provide a small reply box.
 - Drilling down into the folder view would show you all your folders, the rules associated with each folder and email addresses.
 - Drilling down into a contact's name on the detailed table would show various contact details of that contact, the emails and attachments that you have sent and received from this contact.

By pulling information relevant to the facet being inspected, user interfaces can become more useful.

This could be implemented as a zoom effect where the focal widgets are scaled upwards and less relevant widgets disappear as if they were to go past and behind the user.

A drill down interface is unlikely to be easy to design for because combinations and relevance would have to be determined in advance.

Similar:

Potential Integration:

Existing:

42. Context As an Explorable Web: What can I use?

The context available in a given situation should be easily accessible and discoverable. A context tells a story and gives way to opportunity. This information is currently discoverable through consulting documentation, asking questions or using debugging tools. Development environments should present what has already been calculated and what is available in an easy way.

For example, a request is made, the server knows what user is making the request and the user is in a particular stage of the workflow. Information about the previous stages of the workflow is part of the context of this request. This data can be rendered in an interface to show what really is available - seeing the data available makes it easier to find out what you want to use when you don’t know what you’re looking for.

43. Cost-Aware Computing

Algorithm complexity and hardware specific characteristics could mean that a given algorithm or library is more optimal for certain configurations. An algorithm used on a desktop may not always be the best on a mobile phone. A library used on a server may not be useful on a laptop.

The operating system or host environment could pick the best algorithm depending on various conditions:

Existing:

44. Interface Defined At Authorship: Meaning Added Later

You want to create a document. You want:

Traditional content management tools define rigid input formats and inflexible GUIs for inserting content. Exacerbating this inflexibility is the tight coupling of this input interface to its display. There is a one to one mapping of input to output. For example, you want to upload an image in a popular CMS. You are given a gallery of previous uploaded images and an upload form. When you click an image, the photograph is inserted but the widget has decided how the image will be placed and will appear on the page. The ways you can insert the image is limited to the functionality provided by the photo input interface. This model is at odds of how well people understand tools: while writing a document, I do not care or even know how I’ll integrate other content into my article. What’s important to me is that I can insert placeholders for content and have these placeholders be processed later. In fact, I might not even be the same person who integrates the content together because I might be a content producer, marketer, designer or a journalist.

I might not know how everything should look or act in my article until later. A tool should allow me to:

By treating the transclusion points as independent items to be tracked and controlled, we have better control of content that can evolve over time and stay consistent between pages. The transclusion points are ‘holes’ to be filled by some arbitrary process defined in the future or not at all.

For example, this is an excerpt from such a user interface:

Description Handler Uses
<video/> XML element YouTube, Vimeo URL handler Used on 4 pages
<gallery XML element 2 handlers: Slideshow handler, Embedded Flickr handler Embedded Flickr: 5 pages
Slideshow: 1 page
# Hashtag Twitter link
[bbcode][/bbcode] BB Code handler Used on 1 page
<sql> XML element No handler registered Used on 2 pages
<code> HTML element No handler registered Used on 5 pages

Interface defined at authorship is similar to mail merge except the user does not care about the ‘field format’ and how the fields are transformed can be customized. IDAA can make web development simpler as content creators, designers and programmers stay in their respective domains working in parallel.

The interface part refers to how a developer did not actually specify how data should be input to give the data meaning. Detecting potential meaning is possible providing there are generic handlers such as XML elements.

Potential Integrations:

Existing:

45. Community Idea: Secure Configuration Distribution

Many applications ship with default configurations that are more likely to be vulnerable. A community could discuss the security of configuration options and offer files or patchers that ensure that common applications have proper settings. Examples would be preconfigured settings for Firefox, Chrome, Adobe Reader and Word.

46. RESTful Living Documents

The semantics of (handler(intention, data, context) → output) described by IDAA could be handled by REST architecture where every inclusion is actually the definition of a HTTP request.

For example, an image is frequently needed in multiple resolutions, sizes and quality. Typically these variants are named based on size or purpose and uploaded separately. A IDAA REST architecture would map the intention to the HTTP protocol. For example, a website logo with a single name (http://example.com/logo) that appears in the header of the website might have a content type of header logo while the logo for the footer has a content type of footer logo. From a user’s point of view, this might be easier to understand than having separate files header-logo and a footer-logo file and keeping these files up-to-date. How these resources are actually fetched depends on the handler - it may be preferable for the designer to refer the intention of a logo but have developers map the content-type to plain directories.

Potential integration:

47. Group and move sections lists easily

Moving around blocks of text through online rich text editors and default browser text editors is painful compared to dedicated tools.

I should be able to arbitrarily group regions of text or lists and move them up and down arbitrarily.

Existing:

Potential integrations:

48. Branching Libraries

Many frameworks and application architectures simply provide common abstractions for branching on input data, such as, given X then do Y. For example:

Sometimes we want to use X as if it is a Y. Principles in one area can be used to tackle something in a completely different area using a non-traditional style.

A branching library allows the branching conventions of one ecosystem to be used in another which can potentially speed up development and permit reuse. Of course these have to be specifically implemented.

Existing:

49. Linked Representations

A file can typically be converted between formats. Sometimes it is necessary to keep a file available in multiple formats, such as a HTML file and a PDF. In this case it is desirable that:

Linked representations would be useful when files that are combined to create others or its converse when files are split to create others.

A linked representation would automatically split the files when a source file is changed or trigger a combining action when the components are changed. If software is written from composable actions or through data views on the underlying data, this could even be bidirectional. This would mean that editing the source image or the individual pieces would cause the other to be updated.

Existing:

50. Renderers

In a living document it is infeasible to manually markup all semantic information. It may be nicer to scan or interpret documents and automatically insert meaning.

Example Handler Uses
555-555 Phone number handler Used on 1 page
744 UNIX Permissions handler Used on 3 pages
~/known.file Known folder Used on 5 pages

This can be accomplished through dedicated programs and regular expressions.

Existing:

51. Native Web Libraries

Web libraries are natively implemented versions of JavaScript libraries. The interface of a web library is actually JavaScript. A web library is always written in JavaScript first. When performance problems need to be resolved, the moving parts can be implemented in a non-JavaScript language and installed in the browser.

The idea is that native libraries can be added to stand-in for JavaScript libraries purely for performance reasons. These native versions would be able to act directly on the browsers internals as if the API calls were native. There should be no difference in functionality between the JavaScript library and the web library.

navigator.require('http://example.net/library')

Where library is a URL to a JavaScript file that is used as a key to find an installed web library. The JavaScript version is used as fallback.

Usecases:

Potential integration:

52. Account Management Protocols

Managing digital accounts is tedious as each account provider has its own graphical interface and no machine readable API. An account management protocol would allow the following:

This would allow a user to change an email address or personal details once and have it take effect everywhere.

Potential Integration:

53. Web State Machines for Testing

A web page can expose a state machine to indicate multitudes of state in the web application. The state transitions can be updated incrementally as things happen or as an on-demand introspection. A testing tool can therefore verify behaviour between interactions.

pageobject: {
	"warning.visible": true,
	"searchterm": "buckets"
}
assertions: {
	"warning": {
			visible: true
		},
	"search": {
		"value": "buckets"
	}
}

A page in a web application can have a Javascript API that reflects the expected user usage pattern.

54. Community Idea: Tech Stack Slice

There is no website that allows the comparing different technology stacks. There would be a page for every permutation of technology, for example the following might be common technology pairs:

These pairs can included in complete technology stacks such as Linux, Apache, MySQL and PHP (LAMP). This may go increasingly in depth to particular database abstraction layers, web frameworks and libraries. Each page will have a list of advantages and existing projects using this stack. As projects are added, the stacks will become more specific. Attributes from individual technology interactions will rise up to the entire stack.

As a user of this site, I may begin by exploring:

Existing:

55. High Level Project Overview

When joining a project, there are high level asserted approaches to solving problems adopted by the project. This can be choice of technology stack and style of architecture. I should be able to see this in a single page.

This overview should be an easy to update and shareable.

56. Use Microservices in Projects (Microtools)

We do not always need a heavyweight system for maintaining data. Wikis and document files are frustrating to update and typically fall out of date. Microtools are very specific tools unlike Wikis and management software, they serve a single purpose and make keeping track of data as simple as possible.

To be lightweight but useful, these examples could be implemented:

57. Acceptance Criteria Issue Tracker Integration

WHEN I click the search box
AND this is my first time I've used the search box
THEN the text should be cleared

This acceptance criteria follows the convention for WHEN and THEN in BDD style. Developers or testers may write automated tests with BDD tools and copy these strings into source code. This is introducing a gap between where the ACs are defined and the place where they are tested. Ideally the testing should occur against the story and the AC from the story is the source of truth. The following has taken the AC from the control of non-developers through copying AC into code:

var ac = {
"I click the search box": function () {
	searchbox.click();
	},
"this is my first time I've used the search box": function () {
	return searchbox.hasBeenUsed() === false;
	},
"the text should be cleared": function () {
	return searchbox.isEmpty() === true;
	}
}

ac["I click the search box"];
ac["this is my first time I've used the search box"] &&
ac["the text should be cleared"]

If the story’s AC changes, the above test will fail because the test no longer matches the acceptance criteria.

Strings may not be the ideal representations of acceptance criteria for they could change. AC may have similarities with other stories and duplication creates maintainability problems. These may need a more robust link against the code that tests them.

Builds now run acceptance criteria tests so that functionality is not broken through future changes.

Potential integration:

58. Microtests: Cross-Project Test Suite

Many bugs have common symptoms. These symptoms could be collected into a suite of tests that apply to all projects as a form of sanity testing. The following should trigger errors:

59. Security Proxy

The internet has made it easy to leak sensitive or confidential information. A dedicate web proxy could scan all traffic for keywords that match known sensitive information and reject it. This requires users define what they deem sensitive.

This is especially important as data is always being passively collected by web pages in JavaScript.

Potential integration:

60. Operating System Field ‘Firewall’

Form fields and widgets are sanitized for sensitive information before being made available applications. This prevents information being pasted accidentally. This is like security proxy but for input fields.

61. Visual Git Release Management

The branches of Git projects can be visualized as connected circles where branches are created and merged back. It would be nice to generate a live version of this diagram horizontally so one can follow development of a project and understand the release structure.

Existing:

62. Salary Structure as a Program

An open source program could determine your salary. There may be various criteria that the program records and tracks so you are paid properly. There would be chains of verification of facts to prevent abuse. This could be tested and should maximize transparency in an organization.

Similar:

63. Website Annotation

Adding notes to websites can function as a form of memory aid. It should be possible for me to add and save notes to a web page in case I come back later.

64. Peer to Peer Backup

Backing up files to family and friends makes sense as a form of distributed off-site backup. This has been done by numerous services such as:

Security could be enhanced by ensuring files are broken up into pieces in the style of Bit Torrent.

Potential Integration:

65. Open Source Subscription and Bounties

Open source projects benefit from contributors and financial contributions. Donations have more impact when they are larger and by multiple people. A open source subscription would be a monthly payment that combines donations from multiple people into one large donation for a project of choice each month. The community would vote what projects to donate towards. Donations have no expectation of special requests or work to be completed.

Open source bounties would be to implement a new feature or fix a bug.

Existing:

66. Wizards and Forms Request Data

Many website forms and native applications with wizards request data across multiple pages. These applications should expose the entirety of the data they are asking for through a scriptable interface.

67. Hardware Review

A hardware review process shows how powerful your current set of detected hardware is.

Existing:

Potential integration:

68. Right Click Outsource

Task management between computers is an unsolved problem in desktop environments. Many users have multiple devices. Sending tasks, inputs or outputs to different computers is painful. Usually sending audio to be played through another computer, taking control of an application running on another computer, sharing files or streaming data to other machines requires special software.

69. Internal and External Configuration

There are two kinds of software configuration. Internal configuration is that application directly uses such as a browser and its own settings. External configuration is configuration that has been applied by the application’s working environment. Both should be editable through a common interface.

70. Proximity Sharing

When you want to share files or content to people surrounding you physically, transfer is not that intuitive. With fixed workstations, it might be useful to drag files to the edges of the screen for the file to be ‘dropped’ into the adjacent workstation.

71. Gaming Interfaces for Work

Resource management, planning and configuration in video games provide simplified but effective and understandable controls and visibility over progress and process. Commercial software would benefit from visualizing the process and progress of work.

Gamification as currently realized by industry is not the same as using game interface design in business. The appeal is not making work feel like a game but to make work as clear and useable as a video game.

Examples:

A clinic has 3 general practitioner rooms, a waiting room, staff (receptionists, GPs, nurses) and stock of medicine. These are some of the resources being managed:

 * timing of appointments and staff tasks
 * physical space for procedures
 * available personnel
 * financial
 * happiness of staff and patients

With a gaming style interface, we can see at a glance whether or not the clinic is performing effectively:

 - we would see a visualization of the clinic layout, geospatial representations of the world make things more interesting as we can observe what is going on
 - we would see the staff counts and locations
 - we can see medicine expiry dates and stock levels
 - we can see the concurrency of the system if we lay out truly cohesive integrated timelines of when things are meant to happen
 - we can ensure that tasks are distributed fairly

We can answer questions:

 - are there too many patients waiting?
 - are GPs spending too much time with patients?
 - are cancelled appointments causing wasted physical space?
 - are doctors able to provide adequate personalised treatment in addition to performing paperwork?
 - is there a risk to the current combination of waiting patients that could pose a health risk?

We can adapt the rules of the game and check the results:

 - a room becomes unavailable for use by patients perhaps due to a technical fault. How will we assign patients and GPs to rooms now?
 - can we predict what repeat patients will need in terms of medicine so we can order less frequently?
 - can we detect when staff members are in demand to minimize waiting?
 - how can we make patients feel they are not being rushed and waiting endlessly?
 - what kind of data can we learn from a patient's habits: are they always late and can we fit another patient in quickly?

Potential integration:

72. Best Practice Q&A Feeds

Good practices are a social construct and not given visibility in computer systems. Desktop and application help are too static to indicate the most up-to-date industry best-practice. A ‘best practice feed’ tool would be a peer reviewed support mechanism to provide advice and feedback when machines are being used.

To accommodate the variety of opinions, organisations and individuals can publish their own BPF. When an application is installed, the authors may bundle a BPF to help users starting out.

There are similar existing implementations. As a standard this could be created and completed with standard tools and visualizations. This can be a microtool where Q&A are provided in a standard format.

Similar:

73. Web Of Trust Recommendations

Recommendations can be decentralised. You add people that you know and share your position on a concept. This could be:

Opinions toward concepts can be distilled to how people classify or categorise something and the order and the weight that they give those categories. When asked why people like, approve, dislike and disapprove of something, there is likely to be determining factor. A web of trust recommendation system attempts to find shared categories and weights rather than those that have similar ratings. Categories can have weights and weights can have categories so that users can reinforce held views.

Users could also be asked to provide explicit recommendations. They are asked to consider similar content within their own collections.

If you like X then you might also like Y.

74. Mounted Email Attachments

Email attachments can be exposed as a file system. Opening a mail client and downloading an email attachment is tedious. It should be possible to grab attachments from the file system.

ls /mnt/mail@example/john/
attachment1.doc		attachment2.jpg

Alternatives:

75. Competition Streams

Organisations offering products or services should permit access to a stream or feed that provides data about their offerings. This data could then be aggregated by browsers or third party services to optimize the offers to display.

76. Voluntary Data Mining

A user should be able to contact a retailer, supplier or manufacturer and ask for product recommendation given criteria. The organisation requests specific pieces of information that it will use to correlate to past purchases and offer suggestions given the target market. The customer gets a tailored recommendation from the retailer and the supplier gets accurate information about the customer and what they were looking for.

77. Data Disclosure Tracking

Accessing a service or transmitting data reveals metadata and deliberate information. The knowledge of such disclosure should be trackable by the disclosing party.

People can then understand what information they are revealing to different parties. Inferences can also be made upon this information. For example, it is possible to infer that if an address is known, a postal code can be determined.

Your [email address, IP address, location, phone number] has been revealed to the following actors:

 * the web server amazon.co.uk on IP xxx.xxx.xxx.xxx
 * the noreply@amazon.co.uk email account
 * your mail provider, example.com

78. Cohesive Integrated Timelines

Calendars can help connect relations between activities and act as a memory aid. The information from a user’s interactions across multiple devices and with multiple applications could be combined into a single view. A calendar view of my system log could show:

The calendar can serve as a workspace if activities can be segregated by task or goal. Tasks can be spread over days, weeks, months and years where ability to view past activity would be contextually useful such as:

For example, when you are looking to buy a new vehicle, you can look at your time line for this task:

Potential integrations:

79. File Wires

Keeping the data within and between files is difficult to keep synchronized. It should be possible to ‘wire’ up portions of files with other portions or other files so that they stay synchronized. This would be useful:

The file wire infrastructure would:

The ‘wire’ is the binding of data between two locations. Depending on the format, this could be anything from:

Essentially, file wires turn every decomposable part of a file into a mail merge field source and destination but the field references are out of band and need not be stored in the file.

Potential integration:

80. “Playhouse”: Repeatable Prototyping

Most rapid application development tools force developers to work within the confines of the tool and make it difficult to graduate to a realistic environment. Setting things up and configuring software is an impediment to prototyping ideas. A developer playhouse would take many different technologies and let them be experimented with from one interface without wrapping up the underlying technologies with proprietary code:

Examples:

When Playhouse is installed, you point it at a folder.

 * You click 'Express' and are given a panel for your app.js, your NPM dependency file.
 * You select 'Chef' and are given a tab for 'Infrastructure' and are given a tab for a new recipe file and a SSH terminal.
 * User submitted recipes are browsable on one side to get started with common applications or stacks.

Existing:

Existing Examples:

81. Widget Studio

A widget studio is a content management system for the repetitive sections or widgets that are used on a website or web application and are managed as assets in addition to the web site. The widget studio is is like a model editor for designers. Every single state a widget supports should be explicitly specified by the widget studio.

Potential integrations:

82. Inline HTTP Microservice Compilation

When writing a controller we can interact with a library directly or we can interact with a remote service and offload the work to another machine. For example, Facebook uses RPC internally so that various microservices collaborate to fulfil a request. Inline HTTP microservice compilation would require a developer to always interact with a library through a HTTP interface. This would involve a single web request fanning out to many requests. If performance problems become an issue, the backend server behind the HTTP service can be ‘inlined’ or ‘pulled into’ the code base and replace the HTTP calls. That a HTTP interface is used should not cause overhead if a compilation or transformation step is used that avoids the network stack altogether. By using HTTP as the common interface, functionality can be pulled into the application layer or offloaded to a remote server on demand.

Inlining code may require integration code that understands the project or sourecode of various web frameworks, such as a Ruby on Rails or Node.js project and knows how to pull in the code into the codebase. The possibility of rewriting code at compile time could further be used to improve efficiency.

If this could be implemented dynamically, servers could become truly elastic: when resources are plenty, the microservices run locally. When resources become constrained, the microservices run on separate machines.

Potential integration:

83. Data Dependency Injection

When a web server handles a request, it inevitably fetches and processes data to fulfil and display a response. In a complicated web page, data may be used by multiple widgets and there may be overlap. This should not result in duplicate requests or needless processing.

Inversion of control (IoC) containers could be used for widgets and the data they need. A widget should not be directly instantiated with information - it should pull the data it needs from its environment.

84. Cache Timeout Read-in

The statelessness of HTTP means that data is requested multiple times in order to fulful a request. For example, a multiple page form will typically involve queries to return the logged in user, the state of the form and the fields that have been completed. This data loaded by a web server in a controller may be useful across multiple requests. Memory caches keep data from expensive requests in memory until the next request. These caches need to be explicitly requested for the data to come available. A predictive cache read would associate a timeout with each HTTP request for when the data should be re-loaded into memory. When a user submits a form there will be a predictable delay until the next request. This lump of data - potentially representing the output of many queries - can then be associated with the user HTTP request. This data will only be read back into memory when the time delay elapses as a way of preempting the user’s next request.

Potential integrations:

85. Software Metadata

The infrastructure required to support software is spread across disparate services, servers and protocols. This information could be kept together in a metadata file that represents that piece of software:

With this information it might be possible to:

Existing:

86. Friend Pipe

Sending a file or giving things to other technical users is harder than it needs to be. It should be possible to pipe things to friends and have the transport mechanism be determined behind the scenes:

file | friendname

This can be combined with a ‘friend package manager’.

friend add <email>

Existing:

87. Interface Coalescing

When similar events occur in succession where each in isolation would have displayed a dialog, there is a risk that they block and have to be dealt with separately or they stack on-top of one another. Examples of where this is often a problem:

Interface coalescing means that a singular dialog can ‘coalescing’ with future dialogs to provide a better suited interface for handling multiple items.

Examples:

88. Batching Notifications

Desktop environment notifications such as email or instant messages can be distracting. Events do not always require immediate attention and can be delayed and delivered in batches.

89. Code Journey

Learning a code base should be easy to start and supportive. An interactive code base exploration tool can:

Existing:

90. Views of Data

Applications such as wiki or ERP applications are typically monolithic where the full application is absolutely necessary to interact with the underlying data. Data conversion is needed to move data between ecosystems. Conversion is less useful than a view over data. When we have a view over data, we can use multiple tools to interact with the same data.

Using views may be less efficient because data is not in an optimized data structure. For example, running a join query over a CSV file is likely to be slow. A view architecture could support this in the following ways:

The user should not care what format or representation the data is in - only that they can interact with the data in multiple ways. It should be possible for many applications to operate on the same data structure.

Existing examples:

91. Template Virtual Machine

At its basic level, templating can be considered a block of memory split into dynamic and static regions:

All this does is replace the generation of the contiguous block of bytes [static, dynamic, static, …] with a higher level representation of the output. Servlet layers and templating engines map the output page structure from many nested function calls and branching - the Template Virtual Machine essentially directly maps the blocks to the output. There may be the following benefits:

Similar:

92. Personal Data API

Rather than supply a collection of personal data to remote services, data should be requested from the user’s machine or data custodian through an API by the remote service. This would keep all the data in a single location and ensure that data is kept in synchronization. This could be implemented by browsers.

This also allows a user to track what data was disclosed to which parties.

Potential integration:

93. Shell Output Pinning

The output of one command can be useful while running further commands. For example, a search of a directory would give a list of files. It may be nice to pin this list to the top of the shell and allow the user to work their way through the list.

Examples:

Existing:

94. Policy Tracking

Digitally serving legal agreements, policies and terms and conditions has become industry practice without any tools for users to manage, track and interrogate legal documents. A policy aware system can track and display relevant policies while people use computer systems so that people understand the clauses that apply in a given circumstance.

Legal documents that state a valid action are supported through the interface if there is a digital procedure to fulfil such request, such as a refund.

Existing:

95. Community Idea: Distributed Development

A pool of developers can collaborate to build a system if the individual pieces of code are well defined enough.

Developer 1 logs in and picks feature A to implement.
Feature A requires features B and C to exist.
Developer 1 describes B and C at a high level and creates an imaginary interface how these features might be used if they existed with input data corresponding to outputs.
Developer 1 implements feature as much of feature A as possible.

Developer 2 logs in and sees that Feature B and C are still to be implemented with the imaginary interface defined by Developer 1. Developer 2 implements features B and C, ensuring that the interfaces needed by Feature A is maintained.

Developers collaborate by breaking up problems and shifting other ones to others. A developer operates on a small portion of the code base at any given point so that ramp-up time until productivity is low. Developers jump between features frequently.

Potential integration:

96. Encyclopedic Literate Desktop

Computer systems and interfaces are obtuse and do not describe what they are doing or how they function. A desktop environment should explain and describe software as if it were a living encyclopedia. Computers can be more easily understood if they allowed what’s on screen to be functionally decomposed and explained.

These would be displayed in an overview style format in a similar style to that of a landing page for a product or service online. Each section above might be expandable (such as select a feature to learn how it works.) and linked to further information to learn more.

An advanced user should be able to view the source code of an application in a literate interface. The emphasis is of a readable view of the source code as opposed to an editing environment to help the users understand how this particular application functions.

Goals:

Potential integrations:

97. Community Idea: “Tracked Reasoning”

Viewpoints of a discussion can be identified, related and analysed independently. When a user writes a post, the user can break up the post into separate viewpoints or assertions. These assertions may be ordered logically such as, A implies B then C. Posts will then be cross referenced to see the relationship of each viewpoint and what would need to be true or false to counter an argument.

98. The Desktop is an Integrated Development Environment

A desktop environment is a development environment except windows and widgets are the files and the user’s inputs are the lines of code. A desktop environment should be malleable to change in a similar way that the contents of the DOM (Document Object Model) of a web application can be easily changed. A web developer does not need to re-compile source code to change how an application appears.

If applications were designed to separate:

Then the desktop environment and the user can override parts of the above behaviour of the application without damaging internal state of running applications.

Example: A configuration file 

 - A simple visualization of a configuration file is a plain text editor.
 - The next layer may be a tree structure to navigate the blocks of the file.
 - The next step would be to provide proper widgets for every value.
 - The next step may be wizards to generate certain blocks of the configuration file.
 - The next step may be to provide a dashboard and interpretation of what the configuration
   file is doing from a high level. Such as a nginx dashboard with icons for proxying. (representational computing and data views)

Deployed applications on desktops preside in an impoverished environment compared to the environment that was used to create them. This makes installed desktop software inconsistent between installations and brittle. Various products bundle full-stack servers traditionally used on the server-side. These include web servers and databases. The provision and configuration of these servers should be no different to that used in cloud environments or in development. The desktop environment should be using provisioning tools such as Docker, Vagrant, Chef or Puppet behind the scenes. For example, installing a product that needs a MySQL database would use an existing running tool if installed and is of the correct version or will install a new copy. It’s a complex engineering problem to make this possible, efficient and simple.

Example:

Title bars

The top of every window in a desktop environment could be broken down like so:

Everything is composable

A desktop environment essentially becomes a website in the sense there is a link between what is being displayed and how the user can interact with it or edit it. Every on-screen component can be customized, re-ordered and adjusted. Desktops become living infographics.

Integration:

Existing:

99. Directories Are Portals

A directory can be domain specific and relevant to the types of files displayed. The layout and grouping of icons should be customisable.

Bubble back grouping

Application portal

Existing:

100. Personal Integration Framework

Online tools like Zapier and drag-and-drop workflow systems enable users to mix up online services - this is something that should be possible across devices.

This is like a package manager for normal users except that full applications are not being packaged - behaviour and configuration are.

Existing:

# More ideas

There’s another 101 ideas in Another 85+ Ideas for Computing on my Github.