I’ve spent the last few weeks talking to a lot of people – including all of you. Many of you have come up with amazing suggestions for Plexus. Some of you have gotten a song-and-dance form me about thinking about front-ends to Plexus. Which leads to even more amazing suggestions, and ideas. It seems that [...]
No file format survives its first encounter with database schema. As designed, jCard format was a bit wrong – more a list than a dictionary. I’ve taken out some of the spurious syntactical elements, and added a new keyword, ‘connections’, which represents the list of connection points. The new jCard looks like this: { “vcard” [...]
The consensus opinions seems to be that the XHTML version of the card should remain named ‘hCard’, in order to avoid further muddying the waters – and also to entice hCard devotees to give Plexus a whirl. John Allsopp suggested ‘jCard’ for the JSON version, and I rather like that. Henceforth pCard is dead – [...]
John Allsopp, the man who (literally) wrote the book on microformats, has given pCard format a once-over. His suggestion? “Why not simply leave it as hCard?” The differences between pCard and hCard format are – at this time – entirely semantic. Something is a pCard because it’s to be used with Plexus. Something is an [...]
I’ve spent a few days thinking about pCard format, here are the initial results of my work… This is the XTHML microformat, which is completely compatible with hCard microformat: <div class=”vcard”> <span class=”class”>Public</span> <span class=”fn”>Mark Pesce</span> <span class=”nickname”>mpesce</span> <span class=”uid”>6fa459ea-ee8a-3ca4-894e-db77e160355e</span> <img class=”photo” src=”http://upload.wikimedia.org/wikipedia/en/3/3d/Mark-cafelife.jpg” atl=”Mark Pesce” /> <a class=”url” href=”twitter:mpesce”>Twitter</a> <a class=”url” href=”feed:http://blog.futurestreetconsulting.com/?feed=rss2″>The Human Network</a> <a [...]
I’ve started a basic list of things that need to be designed and implemented in the prototype. It’s on the wiki. Feel free to contribute. But remember, KISS.
A big part of Saturday’s conversation with Tony Parisi concerned the Plexus front end: what does it look like, how does it work, how does it talk to Plexus? Most of this has intentionally been left up to the designer/developer/implementer because there is no one right way to design a Plexus front end. If Plexus [...]
I think we’d all be delighted with a mailing list to discuss design, development and deployment issues. The question is: who’d like to set one up? (Not me, thanks. I have enough on my plate.) Update: Tennessee has set up the mailing list on Google Groups – the link is in the right-hand column.
One of the most important design principles of Plexus is simplicity. The architecture is simple. The functionality is simple. The explanation is simple. Anything that complicates any of the design, architecture or functionality should almost always get pushed off to another functional unit (generally, the front-end). Every technical or implementation question that’s come up so [...]
Posts