This specification of technical services depends on the system architecture.

Core User Services

Core user services are to include:

  • Communication – is all about messages of various kinds in various formats – extended content (blogs) and micro content (short messages). Standard protocols should be supported with a proposal for an extension to message (see subsection below).
  • Aggregation – whereas SNS like Facebook, present newsfeeds and other content based on one relationship type, with multiple relationship types, there are more granular requirements:
    • a need to display content according to that one category
    • an aggregation drawing information from all the categories, which is displayed simply as though there’s only one category
  • Micro-transactions: a polymorphic service that supports many kinds of [small] payments, in terms of monetary payments, virtual goods, and physical goods
  • Localised Calendaring and Events – standard facilities for arranging gatherings will be enhanced by being culturally aware – in terms of special days, times, venues etc. For example, when trying to get people together the system will read who can know what about each other and from that determine some constraints such as ‘This Sunday is a special day reserved for …’
  • Life Experience platform: some of the most substantial content comes from the sharing of edifying life stories structured through various kinds of narrative forms. Sigala enhances this through its relationship structure – thus stories are passed from generation to generation. This service merits special attention to semantics and will benefit from both controlled formal taxonomies and folksonomies, the former being augmented on an ongoing basis by the latter.
  • E-Learning support: e-learning is a more formal complement to life experiences, and as such it should fit around especially the teacher-student relationship. Basic tools should be provided such as multiple choice and survey tools. More sophisticated services may be delivered through integration with 3rd party tools. A key consideration will be authorisation.

Graphical and Symbolic Instant Messaging

Electronic communication has been popular since well before the Web – both in the ‘letter’ mode (technically termed asynchronous communication) as provided by electronic mail (e-mail) and in interactive exchanges (synchronous communication) provided by Instant messaging (IM), often referred to as just chat. In fact early forms of IM also long predate the Web (as in the UNIX ‘write’ command), but messaging was truly popularised with the likes of AOL Instant Messenger.

Whether synchronous or asynchronous, all these services are text-based and even now they are dependent upon a fixed, albeit expansive character set1. Some services, such a Twitter, support links and/or attachments of various multimedia objects, but they are not a core part of the messaging language itself.  Whilst this is a boon in terms of linguistic information, especially for machines to interpret, it comes at the expense of personality: even if we limit ourselves to language, sending short handwritten messages can convey more sensitivity than any number of Emoji or smileys2.

Further, for ideographic (as opposed to alphabetic) languages, as used by more than a quarter of the world’s population, input is already somewhat artificial (using, e.g. Pinyin) or cumbersome, though support on mobile platforms is well-established and straightforward to use (see, e.g., how to enter Chinese for messaging).   However, whilst that is functional, it would be more expressive, more in character(!), to be able to write the characters naturally, recording the stroke order. For the recipient as well as seeing the naturally formed ideograms, it would be even better to be able to ‘play back’ how they were written.

There is already support in messaging apps for handwritten messages: for example, it was integrated in the Messages app in iOS 10, which also came with Digital Touch, supporting sketches.  Indeed, proprietary apps offer a lot of functionality and slick user interfaces, but there’s much less on offer that is cross-platform.  A promising foundation is offered by the Matrix open communications protocol, which also has developed the Riot client, though work remains to be done to improve the user interface.

We propose to make use of Matrix together with a simple graphical extension to Riot app, or else create a new one, to support symbolic messaging.  The representation of such messages needs to be based on some open standard.  One possible candidate may be the SVG (Scalar Vector Graphics) open standard3in which participants use a range of clients depending on platform to compose .svg files that can be sent across the Web (using http, as does Twitter).4 As support for SVG (Basic or Tiny) is now common in smartphones and given the increasing number of touch screen devices, there are now the right conditions for a messaging service. Furthermore, these standards as at SVG version 1.1 detail support for animation5. So the process of drawing (the sequence in which strokes are made etc, ‘online recording’, as it were) as well as the end result (‘offline record’) can be saved. Then the recipient or viewer of such a drawing can play it back. Furthermore whoever has a copy of the drawing could extend it. A simple example might be a game of Os and Xs. Technically, version control could be applied that records successively changes.

Providing a central point for aggregation of such content would then lead to a drawing-based equivalent of Twitter. By allowing more than one person to work on a single drawing, then opens up an interesting example of collaboration (technically CSCW). Furthermore, technologies for image recognition could enable support for pattern matching to the doodles against a database of complex pictures such as photos and works of art. This could even lead to new ideograms. For instance, suppose you want to create a new road sign that represents particular features of a modern landscape. You could take a photo and then try drawing some simple representations until you arrive at the simplest one that returns the desired match.

There are already various experimental and niche tools that demonstrate the capabilities of this approach, particularly some using xmlBlaster, an event driven messaging middleware6– the demonstrations show sophisticated functionality that actually exceeds our requirements7.

How these services are made available to and interacted with by members is discussed next – through an appropriately designed user interface.
 

Notes

1 A pot pourri of technologies and history is available in Wikipedia’s entry: http://en.wikipedia.org/wiki/Instant_messaging

2 The popularity of simple drawings is evidenced by games such as Draw Something. See e.g. BBC News Technology, 5 April 2012. http://www.bbc.co.uk/news/technology-17624172

3 World Wide Web Consortium Scalable Vector Graphics (SVG) 1.1 (Second Edition), W3C Recommendation 16 August 2011 http://www.w3.org/TR/SVG/

4 The first intimation was expressed in a RAMBLE Project blog post by Paul Trafford, Rice Grain No. 2: Jotting more than text. 17 July 2005
http://web.archive.org/web/20090626155924/http://ramble.oucs.ox.ac.uk/blog/RAMBLE/2005/07/17/1121605077981.html The subject was revisited in: Paul Trafford. SVG Doodles for Blogging, Micro-blogging and Messaging, Handheld Musings blog, September 19, 2010 http://handheldmusings.blogspot.co.uk/2010/09/svg-doodles-for-blogging-micro-blogging.html

5 W3C Recommendations: SVG 1.1 (Second Edition): 19 Animation, World Wide Web Consortium, 16 August 2011 http://www.w3.org/TR/SVG/animate.html

6 xmlBlaster home page. http://www.xmlblaster.org/

7 In particular, http://www.xmlblaster.org/demos.html includes GraphicChat, a graphical chat client demo and a chess demo that shows an exciting way of communicating with animated images using SVG.