Raw

Stumbled on this by Donald Norman in some of Edward Tufte's material about PowerPoint :

Technology is not neutral. Technology has properties--affordances--that make it easier to do some activities, harder to do others: The easier ones get done, the harder ones neglected. Each has its constraints, preconditions, and side effects that impose requirements and changes on the things with which it interacts, be they other technology, people, or human society at large. Finally, each technology poses a mind-set, a way of thinking about it and the activities to which it is relevant, a mind-set that soon pervades those touched by it, often unwittingly, often unwillingly. The more successful and widespread the technology, the greater its impact upon the thought patterns of those who use it, and consequently, the greater its impact upon all of society. Technology is not neutral, it dominates.

- Norman, Donald A., Things that Make Us Smart, Perseus Books, 1993, p. 243

It nicely expresses what I've been trying to say in my periodic rants about the tyranny of the browser. Tufte's application of the above to PowerPoint is lovely, now rather than handwaving I can point to something concrete that also blinkers our way of looking at information.

The Web browser as we currently know it has evolved to interact with the Web in a way that's been influenced by perceptions of what the Web is and can be (for example, that it's largely read-only). There's a feedback loop; it's self-perpetuating. There are clear advantages for Web publishers and users in the convergence in the way browsers behave, but this is at the cost of innovation.

Incidentally, Tufte is now a sculptor.

Browsers have certainly evolved since the WorldWideWeb browser in 1990 into pretty sophisticated pieces of kit, supporting rich views of HTML and many other media types, along with a powerful version of code-on-demand through Javascript. But in certain respects they're still very primitive. It was probably unavoidable, but there's a significant conceptual gap between what the browser can do as a general-purpose tool and what it can do as a container for site-localized Web Applications. Take Gmail as an example of the latter - very much the same ballpark as desktop mail applications. But move away from that domain and all gmail's functionality becomes inaccessible. We're still a way off a genuine Web of Applications.

One obstacle to maximizing the Webiness of Web Applications is found around the way buttons are used, directly mimicking the behaviour of desktop applications. But on the Web, the best affordances are associated with links (i.e. URIs + HTTP). In this context we should expect more of Web Applications - that the application should be built primarily as a Web API, i.e. a regular Web Site, so that the affordances are available to other applications. It should be trivial for me to check the contents of my gmail inbox from the comfort of my own Home Page. However I'd hazard that the business models of the big Web brands are likely to hinder development in these directions - Google, Facebook, Amazon etc. run somewhat counter to the open Web, in that they are motivated in keeping you in their domain (or in extreme cases like Apple and MS, in their own devices). Web Intents seem to me to be a good start towards enabling more flexible yet uniformly accessible interactions.

Over the years the read/write nature, or rather lack of it, has been discussed an awful lot. Even though the first browser included an in-place page editor, the current model still doesn't really support this. One big reason for this is that HTML - even HTML5 - falls short of supporting the full range of HTTP methods. The predominant approach to writing to the Web is through major intermediation by Content Management Systems. While CMSs are generally a very good idea, the fact that they're built on an effectively hobbled client means they aren't as Webby as they should be. There are genuine technical obstacles to generic writeability, notably those related to authentication and authorization, though hopefully WebID will help there.

The metaphor of the browser is itself quite limiting. Generally we only have one Web document open - visible on the screen - at a time because we can only read one thing at a time. Even with the development of tabs, the browser still essentially reflects this modal model of Web resources. I think I read about work on accessing data across tabs, but as far as I can see it doesn't exist yet. Ok, desktop applications are also under the restriction that we can only look at one thing at a time. But it's a lot more common to interact with multiple independent data sources/sinks and processing components there.

A browser can pretty much support a general-purpose HTTP client (through script), but because we're so used to thinking in terms of the Web of Documents and requirements there, the one page at a time modality is deep in the mindset. Service mashups, be they client or server-side, all really aim towards focusing down on a (primarily read-only) single-document view. A critical aspect is that traditionally the link has basically just one meaning - navigate to another page (do a GET and display the results). But while a link on a Web of Data could correspond to the same thing, it could also mean 'GET the data and merge it into the local store' or 'use this URI to filter the current view' or any number of pivot-like operations.

Ok, this is in danger of turning into another rant...let me sidestep by highlighting one specific browser affordance.

The Turn-Around Button?

One link-oriented metaphor for the browser Back Button could be walking down a footpath, junctions in the footpath corresponding to the available links presented to us on a Web page. Clicking the back button has the effect of walking backwards to the previous junction. We are still facing in the same direction. But what if we metaphorically turn around? Ok, the outlinks on the page will look just the same, but other data is available, our whole history. Why not present the current page alongside a recent history page (like chrome://history/) so we can hop back further - a turn around button. Yes, the Back Button may drop down a list showing the history, but richer information could be provided in the main window such as the links followed as a tree.

From a data perspective, variations on a Back Button might mean 'remove this data from the local store' or simply 'Undo'.

Dunno. Work needed on RDFAffordances.

See also: Identifying Applications State

Minor tweaks aside I've got Web Beep to a good milestone, basically proof-of-concept.

Boxes ticked:

• Live service
• How it works documentation
• Spec

A good point at which to put it on one side and get on with some rather more pressing bill-paying stuff for a while.

But it'd nice to have a clue on next steps. There are a few potential directions:

Ports

The obvious one is in-browser Javascript. While the HTML5 APIs look the best route long-term, it's not so obvious right now. There are things already around like making .wav data: URIs, and also dynamicaudio.js - which looks very promising, it supplies a Flash player for browsers that don't support the API. Until very recently I expected there to be a need for DSP libraries (there is a dsp.js) but as it happens it only requires trivial stuff and there's the Java to refer to, all easily hacked. (The only "serious" DSP bit is the Goertzel algorithm, but that itself is easy-peasy, already done: goertzel.js, literally only took a couple of minutes).

There might be uses for desktop UI-based codecs, but I don't know what...I might well hook something up to the current implemetation, see if it inspires.

Some kind of mobile device app should have potential.

But this all is all very tied to another dev direction -

Applications

What to do with the darn thing? danbri's put some good ideas down with ChirpChirp (that I've still not fully digested).

Nicholas J Humphrey had a brilliant suggestion, use them on radio - nearly every programme these days (BBC R4 at least) seems to read out one or more URIs.

I've not got a smartphone so am pretty clueless about that kind of Apps, but presumably there are a few around there.

Doing stuff with DSP and/or GA and/or RDF

Building the thing led to a couple of collateral proto-products: a little genetic algorithm-based optimizer and the makings of a DSP vocab/ontology.

There has been work done already around DSP and semweb tech by the dbtune and omras folks. The Henry service is a sweet example of the kind of thing that's possible, it's "...able to perform audio processing tasks to answer a particular query". The shape/scope of their ont does seem a bit different to what I've been finding, though obviously there's overlap. My inclination is to derive what's needed from the running code then later align it with their material.

With a reusable system-description mechanism in place (i.e. a DSP vocab) it should be straightforward to apply the genetic algorithm optimization setup to any system which depends on a bunch of parameters and has a notion of fitness.

I've also got a few other personal tie-ins with this - the opportunity to tie the DSP (and analog SP) bits to the SPICE in RDF stuff I was playing around with last year, and going back somewhat further, updating the RPP vocab from over a decade ago (I'll get these things finished eventually...). From a suitable level of abstraction there looks to be interesting potential overlap with data processing too - check David Booth's RDF Data Pipelines for Semantic Data Federation.

I've just gone live with a little fun service : Web Beep - enjoy!

Comments to G+ please

Last night, after finding out that part of the G+ API had gone public I skimmed their docs and the docs of some of the specs they draw on: Portable Contacts, Activity Streams and OAuth 2.0. Of course it's great that G+ is exposing an API, and great that they're drawing on existing standards. But after looking at those standards I came away shaking my head, feeling rather discouraged. Again and again they contain data expressed use JSON mappings like "kind": "plus#person" (G+ API) and "objectType" : "person" (Activity Streams) and "" (Portable Contacts assumes that if you've got data you're looking at contacts). Aside from the variation in the naming across these, there's a common theme, the assumption that a simple token (like "person") is adequate for definition of something on the Web. How do you know that their definition of "person" is compatible with your system's definition of "person"? Sure, there are the spec docs to back them up, but how do you get from the data to the spec docs? Ok, there's openness in the publication and dev of these specs and standardization to the extent that they're high-profile enough that vendors like Google will see them and adopt them. But in their technical detail they have more in common with pre-Web, offline proprietary formats - "person" means person because we say so, and everybody knows what we mean.

Digging a bit deeper there's reference to the Discovery Protocol Stack which draws on XRD (the OASIS spec for describing resources) and Web Linking (RFC 5988 for defining typed links). Here there's more of an attempt to make the stuff Web-friendly, entities (resources) and relations (links) are identified with URLs so Web-based discovery of further information is in principle possible. But the "One True Ontology" registry-based approach of Web Linking is questionable in a distributed environment (and comparable to schema.org).

The description of things using schema like "kind": "plus#person" looks like what RDF does, except rather than using a Web-based approach to naming (so you could derive a URL from "plus#person", look it up and find out what it means) instead we see ad hoc token-based naming schemes. With Web Linking we have something that corresponds exactly with RDF properties (they are typed links), and if you can look things up in a registry then that's a step in the right direction. We already use registries to decode the meaning of terms in other major vocabularies - e.g. the HTTP media types through which HTML is delivered lead you to the definitions of terms like "strong" in the relevant specs. But is a registry appropriate for every term we're ever going to use? Does a word like "strong" only have one meaning?

Ok, so far there's a phrase which sums up all this: Cargo Cult RDF

But the theory is that grassroots, use case-driven development will tend to create cowpaths in the environmnent, and all standards orgs have to do is pave these. Except it doesn't seem to quite work that way. On the one hand we have the XKCD Standards effect (check the first paragraph on the Portable Contacts page), on the other hand the simple fact that, even with the best will in the world and with good information, people often get things wrong. Take for example:

OAuth [1.0] aims to unify the experience and implementation of delegated web service authentication into a single, community-driven protocol.

[time passes]

OAuth 2.0 is a completely new protocol and is not backwards compatible with previous versions....As more sites started using OAuth, especially Twitter, developers realized that the single flow offered by OAuth was very limited and often produced poor user experiences...OAuth 1.0 was largely based on two existing proprietary protocols: Flickr’s API Auth and Google’s AuthSub. The result represented the best solution based on actual implementation experience. (Introducing OAuth 2.0)

So...even when good, informed standardization is aimed for, flawed technologies built with flawed processes are unavoidable.

But these things are so popular! Vendors and developers can't get enough of this kind of stuff. It's a continuous stream: XML APIs become JSON APIs, microformats become microdata, but the same patterns are repeated again and again.

Years of these developments passing RDF by. Plan A : The Semantic Web still seems as far in the future as it did 5, 10 years ago. The RDF technologies demonstrably work, and adoption is growing, but it's hardly viral. However you look at it, the world of trendy new specs repeatedly steers around that fact. What's a jaded RDF enthusiast to do? Here's what I recommend:

Exploit the situation!

With a continuous flow of different specs that each covers some little part of data on the Web, focusing on any specific development can only work in the short term. A strategy based on technologies that support flexibility and agility, using known best practices of the truly distributed Web is the best option in the long term, so that systems can be rapidly adapted to meet any new requirements. It doesn't matter that e.g. schema.org misses the point, the data is still useful. "Think globally, act locally" is a great expression - in this context it could mean accept whatever the world of Web 2.0+ has to offer, but handle it on your own terms.

In practice, let's say you're developing a system for a particular vertical market: dog leads (I'm getting serious hints as I type). Don't build the system from scratch based on what people in the dog lead market are doing, don't tie yourself to domain-specific schema or protocols. Wherever possible use commodity, off-the-shelf tools. Then if dog leads take a nose dive on the international market you can regroup with a different target - cowbells for cats - using the same tools, and same skill set. The only parts that need change are at the edges. Basically RDF technologies offer a long-term commercial advantage.

Comments to G+ please.

Short version : An RDF Affordance is a resource description which gives a client all the information it needs to perform an action.

see RdfAffordances and AffordanceVocabulary.

My last post about what a Data Web Browser might look like led to some fertile discussion on G+. Essentially Mike Amundsen neatly reframed the question to being one about affordances, pointing to a bit of related prior work by him on Hypermedia Types.

We hold this truth to be self-evident, that presented with a simple application scenario a Web Architect will abstract it into a form that will take decades to implement.

Only joking...

Web Intents and Actions

I was initially thinking only in terms of an RDF-oriented browser (plugin/service) but it does make sense to stand back and look at the bigger picture. For starters, while RDF is ideal for describing stuff like service characteristics, there's no compelling reason to limit the data that's being manipulated to RDF. With that door open, there's an immediate tie-in with Web Intents, a JSON/Javascript way of describing/implementing generic interactions like share, edit, view, pick etc. (As it happens I added a Web Intents repository to my todo list a few weeks ago, the idea being to store the descriptions as RDF, providing a minimal API for using them in browsers as others have described - nice bit of serendipitous tie-in).

Tantek has spotted the potential around intents and in Web Actions: Identifying A New Building Block For The Web looks at common features across existing systems like Blog this, Digg, Read later, Follow, Like, Share, Tweet, +1 (he uses "Actions" instead of "Intents" for essentially the same idea).

We hold this truth to be self-evident, that presented with the potential for open-ended innovation a Microformats Geek will start paving cowpaths.

Again, joking...

On the Wiki - RdfAffordances - Mike has brought the abstraction back down to ground with some more detail of RDF-oriented actions, and with a view to hacking an implementation (on my virgin node.js installation) I've started a vocabulary - AffordanceVocabulary - this may change fairly soon, apparently Michael Hausenblas has done a vocab in this area, that'll get precedence if there's overlap/conflict.

We hold this truth to be self-evident, that offered a simple application scenario a Semantic Web Geek will always create a vocabulary that obscures the purpose of the application and that no-one will ever use.

Not entirely joking...

There is one high-level abstraction I've noted on that vocab page that is probably useful. There's a natural boundary between affordances that are essentially just HTTP (e.g. click through link, replace a page) and those which require more complex interations. For now at least I'm calling the former Actions (let me know if there's a better word that doesn't clash with Tantek's usage) - they are around the scope of Mike's Hypermedia Types and the latter Intents - around the scope of Web Intents.

Comments on G+

See http://dannyayers.com/2011/07/20/FSW-SFW

[I've not got any handling in for ? on the end of titles in my blog engine...sorry if this post appears twice]

[oops, I've not got any handling in for ? on the end of titles in my blog engine...sorry if this post appears twice]

As usual, after the Federated Social Web meet in Berlin I'd planned to write comprehensive blog posts about it. As usual I didn't get far before getting distracted. So far I've done a bit of overview of the conf, a brief note on privacy issues and a fairly random think-piece on decentralized vs. distributed networks. But I haven't actually covered what were probably the two main take-aways from the conf - Federated Social Web stuff itself and the role of WebID. In lieu of something better I'll drop a few key links in now. In both cases things have moved along very quickly in the past few weeks with Google+ and BrowserID, more on those in a mo.

FSW

One big meme was that of the Facebook-killer - basically we need something that has all the user-friendliness of Facebook but not as a walled garden (and with a better story on privacy etc). Step forward Diaspora - you can use it as a service a la Facebook (with which it shares many features), but also set up your own install. There were also a handful of other apps with a similar style. It took me about a 1/2 hour to set up my own install of Status.Net, essentially an open version of Twitter. though I have yet to start using it and probably more significantly yet to connect it up to the other services I use.

Another pointer I must include is to the W3C Federated Social Web Incubator Group. As the charter describes, its scope is pretty wide, including the various emergent protocols and technologies in this space. One of the initial targets is to move forward the Social Web Acid Test - Level 0 (SWAT0) - an integration use case for the federated social web. On the Wiki there are potential use-cases or user-stories that could become part of SWAT1. They're both fairly short so I'll paste SWAT0 and the list of non-W3C technologies from the charter below. The incubator group is encouraging people to join, so if you're interested in this material please sign up.

WebID

To quote from the WebID site, "With WebID, logging into a website is as simple as selecting a WebID and clicking 'log in'". It's a very nifty bit of tech, secure, relatively straightforward to implement, much simpler than most of the alternatives. In essence it's about passing a URI in with a PKI certificate. When Henry presented this at the conf, the audience response was interesting. Although it isn't rocket science, the certificate stuff used isn't very intuitive (personally I have a blind spot on all things auth), so not everybody got it. Of those that did get it, very few could believe what it provided. A question from the audience was telling : "What can be easier than using username + password to log in?". Henry : "One click.".

Although not critical to the functioning of WebID, one of the coolest aspects is that it cleanly supports FOAF (and other) profile discovery, the service can learn more about the user to improve their experience. In other words it's entirely compatible with the Semantic/Linked/Data Web.

WebID was initially known as FOAF+SSL, on the Wiki oh, also here, there are lists of implementations etc. Watch the video and read the notes from Berlin for more.

There's also a W3C WebID Incubator Group.

...

Videos of presentations of the FSW meet in Berlin are online, along with most of the papers.

Google+

Before going any further, I should remind you that we already have a Federated Social Web, the blogosphere. However this is weak on many aspects - the social graph is fairly inaccessible, often poor UIs - in particular feed aggregators are clunky things, immediacy is seriously lacking, identity management and the personal profiles that there are messy, privacy, auth and access control systems are virtually non-existent. Of course all that has left a convenient niche for Twitter, Facebook, and now Google+.

I largely agree with Edd in his (must-read blog post) Google+ is the social backbone. As a competitor to Facebook it does open up the social aspects as a commodity, and it's considerably more open and linkable, i.e. Webby (here's my stuff). I do worry about Google becoming all-powerful in this space, but as they say this too shall pass. I personally believe the nature of the Web is such that any attempts to monopolise or centralize systems will inevitably fail - because decentralized/distributed systems have inherent evolutionary advantages, though they may take time to take effect. So I reckon Google+ should be viewed by Web technologists not as an end in itself, rather as a bootstrap to a more social Web.

Although Google+ doesn't have any Semantic Web features per se, it does a reasonable job of giving people URIs and linking them together. But rather than a niche, there's a gaping void for describing things in general in a machine-friendly form. Whether RDF-oriented linked data activity will expand to fill this void or some Googlesque reinvention (cf. microdata overlords) of RDF remains to be seen, but either way this also seems inevitable (see also Smarter (Hash)Tags and Google+). I'm not sure we're seeing it yet, but with a bit of luck, once the commercial world sees the SEO etc advantages, GoodRelations should cause a large expansion of semwebbiness.

BrowserID

BrowserID is a recent development from Mozilla. It's close to WebID in that it's in the identity space and about secure signing in, but arguably the primary goal is somewhat different. Broadly speaking, it boils down to the payload of WebID being a URL and the payload of BrowserID being an email address. Discussion is ongoing about the (/any) relationship between the two protocols. All other considerations aside, I'd suggest that WebID is more versatile in that there's a lot more you can do with a URL than an email address and because BrowserID is easier to integrate with existing email-based auth, there's better impedance matching with existing systems. I've tried to argue that BrowserID should allow the user to associate a (non-secret) URL with their email address to allow profile discovery etc. But consensus seems to be that keep-it-simple now trumps easier stuff later (WebFinger has been suggested as the route to discovery, I'm not altogether convinced as it's quasi-centralized, requiring a service to assert the email/URL mapping). Whatever happens on this particular point, BrowserID is certainly an interesting and useful development.

- - - -

SWAT0 Use Case

1. With his phone, Dave takes a photo of Tantek and uploads it using a service
2. Dave tags the photo with Tantek
3. Tantek gets a notification on another service that he's been tagged in a photo
4. Evan, who is subscribed to Dave, sees the photo on yet another service
5. Evan comments on the photo
6. David and Tantek receive notifications that Evan has commented on the photo

FSW-related Technologies

ActivityStreams

ActivityStreams is an evolving format for syndicating social activities around the web.

OpenID Foundation

The OpenID Foundation is the group responsible for OpenID-related standardization. Although work like OpenID Connect is a moving target, the test-cases and specification should be compatible with OpenID.

OStatus

OStatus is an architecture combining Pubsubhubbub, WebFinger, ActivityStreams, and PortableContacts.

Portable Contacts

The goal of Portable Contacts is to make it easier for developers to give their users a secure way to access the address books and friends lists they have built up all over the web.

Pubsubhubbub

Pubsubhubbub (PUSH) is a server-to-server publish/subscribe protocol as an extension to Atom and RSS. Servers compliant with PubSubHubbub can get near-instant notifications when a feed they're interested in is updated.

Salmon Protocol

As updates and content flow in real time around the Web, conversations around the content are becoming increasingly fragmented into individual silos. Salmon aims to define a standard protocol for comments and annotations to swim upstream to original update sources -- and spawn more commentary in a virtuous cycle.

SMOB

SMOB (Semantic MicroBlogging) is a framework that enables an open, distributed and semantic microblogging experience based on Semantic Web and Linked Data technologies.

Webfinger

WebFinger is about making email addresses more valuable, by letting people attach public metadata to them.

Federated Social Web stuff.

It seems privacy can't really be pinned down, the definition is evolving. But you can effectively use a working definition (pick one).

Things are different depending where in the world you live.

Your average internet user hasn't a clue.

What's being leeched from your online activity - virtually nobody takes on the implications. But people are learning, they're as far as 1999.

Even when the browser vendors get together and make a button to limit things - still no-one gets the implications (see Aleecia at the link above).

Ok, so far is mostly "duh!".

But there was a lovely little revelation (from Soren I believe) that statistically the people more aware of privacy tend to be those with more disposable income [bum, that's twitterable]. If you want this demographic's dollars in your consumer base, you better get your privacy sussed.

I've been out of the tech loop somewhat the past couple of years, and had decided not to go to conferences for a while. Ennui mostly. But when a Federated Social Web meet in Berlin showed up on the radar, it struck me I might get the shot in the arm I needed. Wasn't far off the mark. Berlin itself I found awesome, but right now I want to get down some notes on the conf. Falk (my new pen-pal) has a couple of overview posts. Good start Thursday night meeting up with Henry and a good crew. Friday morning I was tempted to sit in on the WebID WG but decided to leave them to it, relax in the hostel instead. That was until I got a ping from danbri, flying visit, unexpected f2f. Then the conf. proper started.

It opened with a pep talk from timbl via video link (captured by Dan Romescu, who has also written up the event). Nothing remarkable (aside from how hyper the man can be at 5am local or whatever :), just reinforcement that the notion of "Federated Social Web" is pretty much the same as Tim's notion of how the Web should be.

After that, all the stage stuff was captured on video by the organisers (bravo!).

For most of the presentations and discussion, Facebook was the mammoth in the room. All the stones they've turned over regarding identity, privacy, Web-wiring is astonishing. But there are people generally very well aware of these issues, which was nice.

beh, I'm really struggling writing this up, I get to 135 chars and start counting. Have to do it PowerPoint. The first bullet:

Lessons learned from Social Networking in Egypt (Amr Gharbeia) is really a must-see. A lot of the media bollocks about Facebook and Twitter playing a role in recent Middle Eastern events was true.

A related must-see presentation happened after the FSW event, over at starship c-base. How some European hackers were able to get communications going again after a govt. had pulled the plug - go to about 1700 on the vid here at telecomix (so I'm told, not got bandwidth here to check :)

In short: Mosaic is fairly easy to build on Ubuntu using standard tools, and all the necessary libraries are available through Synaptics Package Manager.

Aside for being a bit of fun, I reckon there's a good reason to play with it. Santayana said "Those who cannot remember the past are condemned to repeat it". Well, ok, but not everything about the past is negative. There's a corollary with something more positive than 'condemmed'. We can look to the past for things which worked well, and use what we find to inform decisions about the future.

NCSA Mosaic is often cited as a reason the Web went viral. So I thought I'd have another look. I'm pretty sure trying to download DSP utilities using Mosaic at Sheffield Poly was my first exposure to the Web (also memorable because it gave Caroline her first migraine). It was a few years before I encountered the Web again, and I think by then Netscape Navigator had come along.

Anyhow, the source for Mosaic is available from github, so I gave it a shot. Presumably I had most of the necessary dev tools and libs installed from previous forays into building, if I remember correctly things like make and gcc become available when you install package build-essentials (it's in Synaptics). So after downloading and unzipping Mosaic source, I cd'd into the dir and tried:

make linux

This didn't get far. There are quite a few dependencies, notably Motif. When the compiler gave up it said what was missing. Googling I found a systematic way of finding missing bits, by installing apt-file and doing things like:

$ apt-file search X11/extensions/Print.h
x11proto-print-dev: usr/include/X11/extensions/Print.h

which says X11/extensions/Print.h is in the x11proto-print-dev package. But not knowing ahead of time whether things were available through apt, I googled the filenames instead...

The libs I had to install were:

libmotif-dev
libmotif3
x11proto-print-dev
libxmu-dev
libpng12-dev
libjpeg8-dev
libxpm-dev

Chances are a clean system will need other libs.
After installing the above, the build then gave up with:

gui-dialogs.o: In function `mo_edit_source':
/home/danny/mosaic-src/src/gui-dialogs.c:2751: warning: the use of `tmpnam' is dangerous, better use `mkstemp'

With gcc, using -w gets rid of warnings, so I tried make -w linux. It ran without errors and said "Welcome to Mosaic", but at first I couldn't see the compiled app, so I tried make linux again, which ran without stopping this time. I'm not sure the -w was actually necessary.

To run:

cd src
./Mosaic

[apologies for using italics a lot - this WYSIWYG HTML editor is buggy with code etc]