futurilla

Quick Test

2010-08-29T13:40:00.001-07:00

Planning on refreshing and relaunching the Futurilla site very soon. Testing posting from iPhone. - Posted using BlogPress from my iPhone

AOL

2007-02-20T02:46:00.001-08:00

Edwin Aoki of AOL has just left the FOWA2 stage, and he was very eloquent about the nature of community, its roots online, and the opportunities and responsibilities we face as technologists. Again, unedited notes:

Edwin Aoki, AOL
The Changing Face of Online Communities and Communications
Community a key promise of the web since the beginning. Webmail is the leading driver of page views. Chat & IM moving rapidly online. Obvious community applications, but also others like eBay, Wikipedia, Amazon are based on communities of interest. Industry trends - disaggregation and syndication. Users seek out the the experiences and communities they're interested in. The Long Tail. Loss of control of context. A challenge for content and application providers. Think about embedding of YouTube videos. Web Apps too will become syndicated. Mashups. Interactions increasingly taking place in situ rather than in dedicated destinations. Community goes mobile, increasingly following users. Time online increasing, blurring between real and virtual - Second Life, WoW. Shared responsibility of technologists. Safety of tools, security/privacy, social effects. Bridging the digital divide, accessibility, age, socio-economic backgrounds. The Future is in the Balance - power/ease of use, social/commercial, online/offline.

Technorati Tags: Communications, Conferences, fowalondon07, futureofwebapps, Internet, Networks, technology

Tech Crunch

2007-02-20T02:13:00.001-08:00

Mike Arrington of Tech Crunch is onstage at FOWA2 and talking in some detail about what it takes to get a good Web 2.0 startup going. Here's my notes, unedited:
Mike Arrington, Tech Crunch

2006 was not a bubble. The hurdle to become public is much greater. $600m vc invested in Web 2.0 startups. Context of cheaper startups. YouTube bought for 3x the vc investment. MySpace $25m/month ad revenue. Companies failing - good sign. The best is yet to come. 1. Have a good idea - invent, destroy, remove friction. 2. Have a business plan (though some of the best had none). 3. Have a revenue model. 4. Build it cheap, test the waters. 5. Avoid a high burn rate. Amie Street music market. Jingle Networks free business information. The Buzz Factor: Solve a real problem, Don't be the 200th video sharing platform, Have a blog, If buzz isn't happening rethink the product. Opportunities: Apollo offline/online platform. DRM and movies/music/tv. Portability of data and services (pipes, ning, teqlo). Mobile (iPhone)

Technorati Tags: Business, Conferences, futureofwebapps, fowalondon07, Web

e-Science Day III part 1

2006-11-17T02:59:00.000-08:00

I'm taking over blogging the first session at today's e-Science workshop as Robert Sharl will be doing the first presentation. Normal service will be resumed shortly, so in the mean time apologies for spelling, typo, and grammatical mistakes. Gregory Sporton introduces The Accessible grid is this week's theme The story so far week one the oportunities. looking at frameworks and environments week 2 was looking at methodologies in practice and collaboration demo. The Accessible Grid Is there a challenge in e-Science. Can we identify what data is being sent and distinguish what is being sent. Firewalls can be an issue in e-Science. Robert Sharl Digital tools/Digital spaces Nature of computer in the digital process and how the computer is seen as part of the creative process Revisit paper from prague but within the context of e-Science Concentrating on Creative Practice & technology and on Ultra parallelism and the VRU useful lessons from what happened at the VRU Digitising the analogue 50 years translating and reproducing the world around us increasing effective badnwidth - accumalitive doublings storage & data processing and the halvings of cost - moore's law Allows digital tech to represent different things from instruction sets through over time to media & genetics Resolution moved from aproximate detail to where it is a perfect version to where we have excess capacity - we start to see metadata in photography the image is only part of the data set e.g geolocational data forms part of the process Performative increases tendencies - the computer is a tool - a digital powerful paintbrush requiring the control of an expoerienced practitioner. there is a move to the desktop - the user becomes the person in control of the process the machine age for ideas metrics of production digital tech - a heavy lifting gear for the processing of ideas equivalent to the steam age for manufacture. metrics are thos of production. any sufficient advance in tech is indistiguishable from magic. Moore's law allows artists to do thing not dreampt of before. belief in A&D is that tech is just a performance gain. Aquisition of tech is done in this was that it is an appliance within a process and faster. Creative play moves from just performance to transformative The singularity is where we are heading. As we head there we cannot see the exponential growth from close up The acceleration of everything Ultra parallelism - a model for virtualised creative research. principles of supercomputing applied to creativity Tools vs. environment tools are discreet and fit into a work flow, deploy them and they work on a batch model - one process at a time. Environments are dispersed, configured around a problem domain and use design patterns they are populated and use a time share model The network is where power is located creative supercomputing not just the physical hardware & software, but the organisational structures and the social structures - the whole network of people and ideas institutionalised tech monoculture normally. tried to look at tech as a matrix of interconnected focused around standards and glue technologies. the techs themselves help to speed up the process. looking for harmonics and synergies The future of creativity looking at tools in a network sense will provide near perfect information, the collapse of distance and the zero-scarcity of processin in 20 years Harnessing transformative effects looking at something that surrounds the whole creative process. turning the tech from lots of units to an environment. dramatic transformative effects Implication for eSciences in the arts The network is the computers new language - eArts rather external ref Tune the tech matrix look for conections harmonies standards synergies Don't deploy getting the tech out of the box, look at the network and the interesting place is the spaces in between Cede control - give up the control we don't get to see the effects of the spaces in between. Dr. Andy Pryke CERCIA, Birmingham University The 3 categories of the grid - data, computational & social Jargonism a lot of it when looking up the term of grid What does it mean rather than the tech technology focused and is possibly a bit confusing what it really is rather than tech sense The grid is a tool it's not the tools it's what you do with them Have to think of ways use this tool Flickr and the grid of access to everyone's images 4 cats actually. the equipment grid is the extra category. control of remote instruments or sensors. Social, Data and computing are the other main cats. The Data Grid 2 terms. Late 90's very specific definition which is part of eScience the wider grid concept goes further back in time Speech - 200,00B.C. through to oral tradition, accounting, cuniform writing, to printing to the Web The modern grid uniform access to data, and can be massive amount. Intelligent data and semantics of data to discern meaning within data currently very large amount of specific data generated and stored Computational Grid from history Abstract thought - speech - accountants - abacus - mechanical calculators through to digital computers The grid computer - the vision you won't need to know about the computer - invisible computing - access to massive amounts of computing power. currently lots of separate grids/clusters. specialised programming and scientific data. calculations need to be parallelised. Now batch processing but needs to be real-time for use by artists. Social Grid - history direct - primative life communicated in a social grid, social interaction, speech again communication physical but at distance e.g. through painting, writing, postal service (networked fashion) and printing (mass communication). communication in a virtual way through telecommunications, instantly at a distance. through recording Social grid the vision - equal communication and abolishing their location - virtual presence. Currently have Access Grid nodes - high tech video conferencing, standard ones such as Skype. MMOG such as Second life closest to virtual reality opportunity to use in ways not planned. Distributed genius collaborative creation over the grid time and tech should be invisible. e.g. Wikipedia, Flickr, B3TA, mash-ups, photoshop tennis - people can add things to a picture. Work using the grid - an example form Michael Takeo Magruder. Working in the Grid example of the Susanne Vega concert in second life. many people creating guitars and clothes in the virtual space and creating the items in the space. The Grid and the Arts? \How do we use it? e.g. as a research tool, for new-media artists?, for traditional practice? Artists in the Lab projects? Precursors to the Grid existed in history. Discussion Tools vs. Environment

e-Science Day II

2006-11-10T03:18:00.000-08:00

I'm at the second day of the VRU's e-Science for the Visual Arts workshops, and again I'll be contributing notes here, as they happen. Real-time Datascapes: Real-time Histories. Michael Takeo Magruder. Michael is an ex-scientist practicing as an artist, His work blurs the boundaries between content, culture, art and technology. He's fascinated with real-time history, the process by which the capturing, reporting, mediation, dissemination and feedback loop has become compressed and instantaneously reflexive. Notes: Much of Michael's work is now algorithmic, his interest lies in the lack of direct control upon the datascapes which he creates (themselves snapshots or samples of the broader datascape which we inhabit). This notion of the artist 'giving up control' is less straightforward than Michael would have us believe; the mediascape that we live in already mashes things up contextually, already strips crucial information out (sometimes as a result of overload) and forces us to interpret things in our own contexts. We might wonder less about what a scientist brings to art here than what art has to contribute to the regular processes by which we absorb and interpret information from the datascape. Engaging with Digital Technology. Panel Matt Gough, Dancer and programmer. Matt's doing some fascinating work on computer-based notation systems for generating dance, looking at internal physiological aspects as much as external effects, and thereby solving some of the inherent problems with using inverse kinematics in dance simulation. Matt speaks very fluently about the difficulties in bringing the worlds of science and dance together, and the challenges to such a reductionist approach. Jean ? Textile designer utilising CAD systems, digital textile printers, digitally manipulated paintings as source material for fabric design. Tactile aspects of traditional practice and initial resistance to digital technology. Notes: There's really too much here to encompass in note form, and if the VRU can get the podcast up soon then I'll link to it directly. Insert something here about this debate on the role of technology for the artist. The Networked VJ. Workshop - Keir Williams & Jonathan Green. Keir and Jonathan are working with MaxMSP/Jitter, Modul8, and Java, and interfaces to iSight cameras and web-based interaction to drive visual effects and real-time synthesised audio on video projectors. They have a live dancer whose movement is triggering a range of visuals and sounds. Keir and Jonathan are manipulating these using a digital mixing desk and a USB gamepad. I'll link to their Keynote presentation directly. Notes: e-Science models & practice: artists in changing media. Discussion. Notes:

Technorati Tags: Art, Birmingham UK, Computing, Conferences, Creativity, Design, Future, Networks, Open Source, Science, Software, technology, Transformative

Foil Disk Storage

2006-11-05T12:57:00.000-08:00

The future of disk drives just got interesting again: Cringley's new company:

Who needs flash in general as a mass storage technology? Our 10-gigabyte 0.85-inch drive can spin up, read or write data, then shut down again, all in less time than it takes to perform the same task using flash while being just as resistant to shock damage and more resistant to heat. That 10-gig drive will cost $24 compared to $240 for 10 gigs of flash, so we expect that our technology will be used for any application requiring more than 2-gigs of storage. The obvious market here is mobile phones, which will become media storage devices.

Technorati Tags: Future, Futurilla, iPod, phones, puppy, technology, Transformative

e-Science for the Visual Arts

2006-11-03T02:31:00.000-08:00

I'm attending the first day of the e-Science for the Visual Arts series hosted by BIAD's Visualisation Research Unit. I'm especially interested in how the development in e-science might impact the broader space for collaboration and the use of high-performance computing: What kind of things become possible when computing power is essentially limitless, all information is everywhere, and all tools are connected? The venue promises open WiFi, so I'll try to update this as the day progresses. e-Science in the Visual Arts. Dr. Gregory Sporton (UCE Birmingham): Gregory is the director of the VRU, and kicked off the day with a broad discussion of the day's agenda, and the relationship between e-science and the visual arts. Notes: Convergence between e-science practices and IT use in the visual arts. The role of Universities in developing an infrastructure for arts, and access to technologies for artists. e-Science as a term is a political tool used to release funding for large computing infrastructure: Over-supply of processing power driving a search for new customers in visual arts. The technology dominates the discussion, but it is clear that people and collaboration is at the core of this. Culture of e-Science.. needs to move away from the culture of experts which has dominated (we can learn from Post-modernism here). Moving the arts culture away from what we see to what is possible. Who owns technology? How do you develop it? How do people access it (role of Universities here and questions about how they make their infrastructure accessible)? New forms of creativity? Collaborative practice? Interactivity? Art that is unfinishable (successive approximations)? Theory running ahead of practice ("what would Marx do with this?"). Create an infrastructure–what would a useful infrastructure look like? How to link technology and creativity? Re-interpretation of training/practice. What is it to be 'creative'? What is e-Science? Dr. Thorsten Schnier (CERCIA): Thorsten is a computer scientist and engineer from Birmingham University. In his talk he focused on what actually constitutes e-Science, the problems in defining this, and what we already know. Notes: e-Science is being made up as we go along, even within the core of the field. What do we know? It constitutes infrastructure - Computing resources, networking, auxiliary services - but the 'Grid' constitutes this plus services, brokers, markets, and middleware. Example of the Se3d program from HP. New markets emerging to provide services to animators and visual creatives, rendering, with organisations like CERCIA owning software licenses and providing services, developing and driving the market. e-Science=Grid+Research? Is it more than this? Is it demand-driven or technology driven? Example projects include sharing databases, joined simulations, CPU-intensive models, multi-discipline work and data-rich experiments. Challenges and problems: Data/Software compatibility, Security/Confidentiality/Trust, Interfaces. e-collaboration. Usability of e-Science Dr. Russell Beale (CERCIA): Russell is from the Advanced Interactivity Group at Birmingham University. The problem with e-Science: It means a different thing to everyone involved, and these definitions are changing, and more being added. Notes: Different views: "only connected HPC", "mainly distributed astronomy", "Science, but on the Internet", "existing science, but with more computers", "simply a bandwagon". Bandwagons can be useful as a source of funding. Move from Single users/systems to Multiple users and single systems to Multiple users and multiple systems. Myriad influences upon Users and Systems which need to be considered (complex systems). Additionally Science itself is changing from looking for patterns to looking for anomalies? This is true also of Art. Usable design is about taking all these contextual elements into consideration (example of security with human user being the most easily hackable part of the system). Little Science, Big Science: enabling widespread data collection and assimilation. Example of bug survey from number plates/headlights across the UK. Non-scientists as sources of data: need appropriate systems with appropriate usability. Need and duty for feedback and keeping people involved, in an ethically-responsible manner. Design and Usability - the aim of design is not just usability. Slanty design - purposefully reduces functionality eg iPod shuffle. Make it simple to do simple things, hard to do unwanted things. Example of Gmail and deleting messages. Clean usability that reduces side-effects of doing things by limiting functionality. What is required for a Creative e-Workspace? Workshop - Mike Priddy: Mike's intention is to open this up to the room now - looking for examples of such spaces. Notes: Creative e-Workspaces - What are they? What do they need? Sharing and social networking sites - Flickr, YouTube etc. - how are these being used? What are the relative merits of closed environments versus open communities? Transformative Technologies or Performative gains? Michael Takeo posits that all systems entail control over possibility and that this is necessary and positive. Gregory Sporton suggests that this is well-understood but is a conscious choice on the part of the artist/originator, and that other ways are possible. Robert Sharl suggests Second Life as an example of a more open-ended environment or platform. Michael Takeo disagrees that this is a fundamental difference between code and art - that code is present in both and constitutes law and limits. TS disagrees and RB develops the idea that while code and standards are controlled, the soft layers on top (people) are dynamic and messy. The Internet is now the real world, and the distinctions are much fuzzier. Dennie Wilson brings this back to the core notion or a space for collaboration and production (as in SL this can also be the space for the work itself, or the work can extend the space). Analogies and modeling the physical world.. do we need the consistency of constraints lifted from the physical world? Julie Tolmie cites her own work as an example in which an entirely abstract mathematical concept was only in retrospect layered with terminology that grounds it in a physical, analogue world. Building the Wireframe. Discussion: Notes:

Technorati Tags: Birmingham UK, Computing, Conferences, Creativity, Future, Internet, Networks, Science, technology, Transformative, Web

WiFi Pie in the Sky?

2006-06-26T02:17:00.000-07:00

from Engadget:

Boeing looking to sell/scrap Connexion?:
After several years of unsuccessfully attempting to coax people into surfing the Internet for a fee instead of sleeping during their international flights, it looks like Boeing has finally given up and started seeking buyers for its Connexion service, according to sources cited by the Wall Street Journal (subscription required, as usual).

I'm really disappointed to hear this, though surely it's a matter of time before it's standard on long-haul at the very least. A wave of WiFi-equipped mobile phone devices seems to be coming for the business market, and if Brain Training and the Nintendo DS lite pushes little WiFi handhelds into a few million exec pockets we can all forget about the terrible in-flight gaming options that the airlines provide, and do something more interesting instead. The big limiter for my in-flight WiFi use was battery power and the lack of a power socket in Tourist Class, not the $27 fee.

Technorati Tags: Internet, Networks, Airlines, technology, Travel

Futurilla MA Lectures

2006-03-14T13:17:00.000-08:00

Following my two lectures to the MA Visual Communications programme at BIAD, I've posted pdf files of the presentation slides: http://sharl.backpackit.com/assets/311/724/Futurilla1.pdf http://sharl.backpackit.com/assets/311/724/Futurilla2.pdf Notes: Here's the Ray Kurzweil site I was asked for today: http://www.kurzweilai.net/ His most recent book is The Singularity Is Near

Technorati Tags: Art, Birmingham UK, Creativity, Design, Education, Future, Futurilla, Internet, Media, Software, technology, Transformative, Web

Panel Discussion Notes

2006-02-08T09:49:00.000-08:00

Selected Live Notes from The Future of Web Apps Summit Steve Olechowski - FeedBurner - announcing open API to Feed Flare Question: Is the future of the web primarily about solving small problems with highly focused tools? More tools, loosely joined. Small apps acting on mostly local data.. would be useful to have different tools act on the same data (Steffen Meschkat). Example of calendar, files and email messages all in same In Box. Functionality from wide variety of sources integrated/embedded into single page. Single sign-ons? Most people use same password everywhere, and apps remember passwords, so problem isn't so big (David Heinemeier Hanson). Email as identifier and authentication key mailed (Joshua Schachter). Question: Should web apps be designed like desktop apps? Consistency or pretty, unique interfaces? We'll see desktop apps designed more like Web Apps (Joshua). Something different about apps which operate in a more public space, the context is different (Tom Coates). Whole class of new user who has come to apps through the web, older paradigms less familiar to them (Steve Crossan). Network applications already there, but it's when we can assume the network connection that things will shift (Tom). Paradigm shifts return (network as computer) but each time there's more infrastructure on which to build (Steve C). Business Models and pricing: What would you pay for this? People happy to pay for something they enjoy or love (David). Determining what market can bear, barrier for entry - eliminate people who would be hard to support (Shaun Inman). Question: How much re-engineering on transition from prototype/beta to scalable app? Constantly re-building as stuff breaks (Cal Henderson). No way you can build scalable upfront without the real experience. Betas are bullshit, everything is constantly rebuilding (David). Question: How do you know you're ready to launch? Can you use that app everyday? Is it ready to use everyday? Then you're ready (David). Question: VCs or bootstrapping? Are you building for the future or an app for right now? If you're building an app for right now then it's never been easier to build a business with the money you're getting in from the business (David). Question: Web 2.0 happening because of standards being in place, or because of a paradigm shift in the way we think about things? Dominant Metaphors come up, seeing this re-emerge, social networking, connecting services. W2.0 not tech dependent (Tom) We now have atomic apps that can work well together (Steve O). Critical mass of tools that allow these ideas to work together quickly, even if the ideas come around (Steve C), and successful models (Tom) Question: Where does Accessibility fit into Web 2.0? AJAX as an approach presents some potetial difficulties but at same time a drive towards more standard code, better built site. Takes a couple of years for this to be figured out (Tom). Accessibility is v. important, but the real world sometimes doesn't allow for perfect execution (Ryan). Can build perfectly accessible AJAX pages in principle, just aas you can build poorly accessible HTML (Steffen). Question: are we going to have different forms of commercial agreements? - interelatedness of services. The API is a contract, though not a legal contract. Will see a lot more connected apps with no legal agreement (Joshua). You have to know an API is secure if you're building a business on it, lawyers probably not the solution, but some sort of uptime agreements - going to be fun :-) (Tom) Question: web app companies with revenue upfront, and others build critical mass first.. how do you balance this? Social software needs critical mass, so they can't charge users upfront (Tom). Keep costs low, get money elsewhere so you can scale it. You can build things very cheaply and work out how you can monetise later (Steve C). More interesting apps being created within the constraint of having to attract users who will pay for them (David). Google seen as web search but they make their money through advertising.. but this wouldn't be possible without the search (Steve O).

Technorati Tags: Conferences, Future, futureofwebapps, Internet, Software, technology, Usability, Web

Steven Crossan & Steffen Meschkat of Google

2006-02-08T09:22:00.000-08:00

Live Notes from The Future of Web Apps Summit Greater Expectations - Reality-Checking the AJAX Web Application Architecture Steffen M from the Google Maps team. Dissecting the AJAX hype a little bit. AJAX boils down to client-side scripting, done the right way ("but the name CSS is taken"). All of the parts are either nonessential or redundant. All scripting on the web is essentially JS, all interactions are asynchronous. "A bad name is better than no name". Classic web apps. On the client there are only 2 events - click a link and submit a form. Each time the action is replace the entire document. All application logic resides on the server. With AJAX, scripted event handlers are embedded in client side documents. In response to events the document is updated, possibly involving a request for additional data from the server. App-specific behaviour us implemented on the client side. Consequences: Sophisticated User Interaction (partial display updates, modifications, animations; complex manipulations possible; user interaction as with pre-web) and Client Side Session State (transient session state managed on client, persistent state maintained on the server, corrects a long-standing architectural aberration - which also scales very badly). The bad thing about doing something right the first time is that nobody appreciates how difficult it was. Web Technologies give us plenty of opportunity to appreciate how difficult it was. AJAX:

XHTML obviously the skeleton of what the client sees.
CSS - layout, fonts, colours.
DOM (Document Object Model) - no transactions, unspecified partial deserialisation semantics.
JavaScript - semicolon insertion (can omit semi-colons at end of lines - to woo Visual Basic users!, single threaded ("but nobody tells you so")
HTTP - XMLHttpRequest (notice the capitalisation, let alone the semantics)
Data Marshalling - XML, but better JavaScript Object Literals

Sounds bad.. "but whatever does not kill us makes us stronger" ;-) Practical Consequences:

Cross Browser Compatibility (different implementation of all mentioned technologies, different but always many bugs, enforces good libraries)
Separation of interaction logic and application logic (implemented in different languages, seperated by flexible and extensible protocol, Seamful integration)

JavaScript: Reputedly not serious (ridiculed for the name; semicolon insertion; surprising scope rules; poorly specified runtime), but actually better than its reputation (custom objects, delegations, closures; rich literals, exceptions, functors; has been called Lisp withC syntax; even the name made sense at the time). Don't be afraid of JavaScript :-) Challenges: Deployment (compilation/packaging, modularisation, cache control), Bookmarking & History (in apps quite pedestrian but so are the browsers), Graceful Degradation (smart reuse of transfer format helps a lot), Frameworks (resist the temptation to build one, because there is already one - the browser)

Technorati Tags: Conferences, Design, Future, futureofwebapps, Internet, Networks, Social Networks, Software, technology, Usability, Web

Ryan Carson of DropSend/Carson Systems

2006-02-08T08:32:00.000-08:00

Live Notes from The Future of Web Apps Summit Building a Web App on a Budget: How we built DropSend. Small companies and freelancers Why it's important: You don't have to be big anymore. Much cheaper to do things now without gigantic investments. Broadband is widespread. People comfortable with web apps. Hardware is cheap. Open source is cheap. What's enterprise? Mass market or 1000+ users. Capable of handling a large amount of users. Under £30k. DropSend, enterprise and on a budget. Sending and storing large files. 9.5k users in 2 months. 5 Servers co-lo at 365 Main. Desktop apps which use API (not yet public API). PHP, AJAX, MySQL. The most important thing? Make sure idea is financially viable. Use common sense - would you actually pay for it? Be cautious about projections. Be pessimistic, then assume 65% of that. Will you survive? Aim for profit, not acquisition. Acquisition is a fantasy not a reality. Forget the 'new bubble?' stuff. How much we spent. Set a budget. Diff budgets for diff apps. Branding & UI £5k. Development £8.5k (smalll equity stake for developer). Desktop Apps £2.75k. XHTML/CSS £1.6k. Hardware £500. Hosting/Maintenance £800 per month (BitPusher) for 5 boxes. Legal £2630. Accounting £500. Linux specialist £500. Misc £1950. Trademark £250. Merchant account £200. Payment processor £500 setup. Total £25,680. Cashflow - have a side business to bootstrap and fund idea. How to get and stick to a budget: 1 year to save the cash. If it takes time it's ok! Building a team: Quiet talent, not rock stars. Offer equity (2-5%). Ask friends for recommendations. Outsource - tried India, didn't work for us, might work for you. Scalability on a budget. Enterprise has to scale but you can't afford it. Buy just enough hardware to launch. Wait to see if you're successful before you spend lots. Build scalability into the architecture. How does app handle running out of disk space? Plan but don't obsess. Keep it cheap: Don't spend money unless you have to. "No stationery - we wasted £1k. Dumb." No new shiny machines. No luxuries. No froo-froo features. Cut right back and launch quickly with very few features. Makes product simpler and easier to use in general. Before you spend £25, check yourself. Make deals, give equity, barter services or advertising (on blogs). Use IM, not phone calls. Do as much as you can yourself (did wireframing, marketing, testing, book-keeping, copy writing. Get friends to help (usability testing). Shop around (first quote was £12k month!). Pessimism has it's place: You'll go 10% over budget and 3 months over schedule. Plan on it and update your cash flow. "Holy crap! Lawyers are expensive". Terms of service £1k, Contracts for freelancers £800, privacy policy £15 (clickdocs). Barter! Free one-hour consultation. Cheap software is your friend. Basecamp, Trac for bug tracking, Skype & AIM, Subversion for version control, LAMP Cheap hardware: £200 Linux box for dev server on own broadband. Marketing: Blogs, Word of mouth, viral qualities to app where it makes sense, writing (great way to raise profile - mags in your customers sphere of reference). Venture Capital? Might need it if you need to scale/expand quickly, you can't wait a year to save cash. You need a solid reason to go the VC route. Why give away 25-50% if you don't need to? What we learned:

Don't spend money unless you absolutely have to
Bring down costs by bartering
Cut features
Be realistic/slightly pessimistic about your cash flow
Plan for scalability but don't obsess

Technorati Tags: Conferences, Future, futureofwebapps, Internet, Networks, Software, technology, Web

Andrew Shorten of Adobe

2006-02-08T07:28:00.000-08:00

Live Notes from The Future of Web Apps Summit AJAX and Flex - shared Web 2.0 themes. Engaging and compelling user experiences. Seperation of data & UI (RSS feeds, Public APIs, Open data formats), Information comes to the user, Standards-based. AJAX limited by browser. Flex leverages the Flash Player. AJAX not designed for high-performance UI rendering, limited UI controls, write-once cross-browser delivery hard, lacks integrated AV, no bi-directional RT messaging support, limited to XML over HTTP, no offline/online working, no screen reader support (?). Move in use of Flash away from expressive content towards an application platform, cross platform/device. 98% reach of Flash player. Flex enables developers to deploy apps to the Flash player. A framework of components. MXML, ActionScript, CSS, Flex Class Library. Application server, J2EE Tier, Integration Tier, Resource Tier. Messaging direct between client apps without server transaction. Flash Player now has ability to view source code (not clear when this is allowed). When to use Flex - as standalone apps: Guided services, Media Rich Applications, Data Management Apps, Data Visualisation. AJAX/Flash composites such as MeasureMap. Tools: Flex Framework 2, Flex Builder 2, Flex Enterprise Services 2 (messaging, sync etc). Flash Player free, SDK free, limited use of Enterprise Server. AJAX on Steroids, Vista on a diet :-) http://labs.adobe.com

Technorati Tags: Conferences, Creativity, Design, Future, futureofwebapps, Internet, Software, technology, Web

Shaun Inman of Mint

2006-02-08T06:45:00.000-08:00

Live Notes from The Future of Web Apps Summit Ten Reasons why you need to build an API APIs take a good thing and make it better. A documented means of interacting with one application from another. A successful API obscures the storage format of the requested data as well as the details of the retrieval process. Lots of uses of APIs by bloggers, developers, dashboard widgets, service providers. 1. Increase brand awareness. People don't care about the API, they care about what it can be used for. Users of APIs are early adopters, technophiles. You empower users/developers and they like to talk about that. This builds buzz around your application. 2. Allow users to own their own data. Pull data out of services, freedom to move, survive. 3. Build goodwill with developers. Saves people having to do the same things over and over again. People have solved the problems already, use it. 4. A perfect excuse for a community. Mint API lets users extend the functionality, this knowledge needs to be acquired, shared, discussed. Pulls people together around these features. 5. Solving programming problems with an API in mind can improve code quality. Preparedness for this is a discipline, clarifies mental model for application. 6. Simplify internal reuse of data. 7. Allow others to extend the functionality of your application. Eg of SVG graphing add-in to Mint. 8. Allows for alternate input systems. Desktop software like Ecto, MarsEdit 9. Unanticipated applications of your data. Mash-ups. GoogleMaps extensions. 10. Turns your program into a platform. http://www.haveamint.com http://www.shauninman.com/

Technorati Tags: Conferences, Design, Future, futureofwebapps, Internet, Networks, Software, technology, Web

David Heinemeier Hanson of 37 Signals/Ruby on Rails

2006-02-08T06:16:00.000-08:00

Live Notes from The Future of Web Apps Summit Introducing a silver bullet for developers: Motivation. A stronger influence on productivity than any other factor. This should be the focus of development processes, need to enjoy the mundane details of what you do. Motivation comes from happiness, so the tools we use should optimise for happiness. How do you go about making programmers happy about what they do? Coding is usually mundane. Beautiful code makes programmers happy. Feeling good about statements which express what is required in an obvious, pleasing, right way. But, your application is not a unique snowflake. You are not special :-). This is hard to deal with, but most of your work revolves around the same mundane details as everyone else. With Ruby on Rails we have optimised for what most people do the same most of the time. 80% is mundane, 20% is special. Convention over Configuration. Config is a big programming task, which is repetitive and hated. Beautiful code doesn't repeat itself. Example of convention of classes linking to tables which are the plural of the class name (milestone/milestones, project/projects). For the special cases you configure, for the rest you assume the conventions. Example also of the naming of web app controllers mapping to the URL without rewriting urls. Flexibility is overrated. It's a tradeoff with readability and speed of coding. Constraints are liberating - if it's easier to follow conventions you'll build consistent systems and not worry about the irrelevant details. Focus instead on what your app actually does. Do the right thing - the clean, pure, beautiful thing. Hard to do - developers have an angel and a devil on each side of them :-) Too tempting to do things the easy, quick way that you pay for in the future. PHP is the devil :-) Constantly encourages you to do the quick dirty hacks, to be a slob. You can fight it, but it's hard, especially when the pressure's on. The angel is embedded in RoR. Conventions. You have to go out of your way to do things differently. Invitations. Embedded invitations to do better, encouraging good practice. Opportunities. To be better and learn more. Allowing common patterns but showing that there are better ways to do things. Expectations. Embedded in the system and the community. Example of running tests with code. Rollback. Ruby makes database rollback easy through blocks of transactions. Validation and associations embedded in the system, and the reliance on conventions makes the code clean and beautiful; almost like plain text. Association chains. Lists model. Ruby everywhere in RoR because it decreases mental overhead of switching, and allows you to move back and forward. So Ruby for embedding in html, for configuration, for functions. Finding the Fit: You feel the hurt - You need to have reached the limitations, found the lack of structure and consistency, degraded productivity etc. Yoy appreciate the agile - testing, domain models. You can skip the vendor - DHH is not a vendor, you want to help yourself. But does it scale? Yes :-) http://www.rubyonrails.org

Technorati Tags: Conferences, Creativity, Design, Future, futureofwebapps, Internet, Open Source, Software, technology, Web

Tom Coates of Yahoo

2006-02-08T04:30:00.000-08:00

Live Notes from The Future of Web Apps Summit Native to a Web of Data. Two months at Yahoo, presentation online afterwards. Design & Web 2.0: Round corners and gradients. Started by Blogger :-) What it means to build for an emerging web. What is the web is changing into? What can you build on it? Architectural Principles. 1. Web 2.0. A buzzword, but also an attempt to make sense of change. Tim O'Reilly Article. Marcus Angermeier cluster map. But too many ideas. Focus on Web of Connected Stuff. The web that was, silos of info, linking together, towards an aggregate of connected data sources, services for exploring and manipulating data, and ways users can connect them together. Mash-ups (not a great term, but useful). Yahoo Astronewsology idea - splice-up of News and Astrology :-). Hybridising data sources in order to make each more useful. Network effect of services. Every new service can build on top of all the others. Every service and piece of data added makes every other service more powerful. Creates massive growth, accelerating innovation, more competition, componentised services and increasingly specialised services. There is money to be made. Use APIs to drive people to your stuff. Amazon prime model for this. More useful and attractive, less centralised development. Syndicated content as a platform. Turn APIs into pay-for service. Keeps hippies and capitalists happy :-) Dangers of NOT doing this. 2. What to build? "What can I build that will make the whole web better? How can I add value to the aggregate web? Drive to own certain types of data: location, identity, calendaring, namespaces. Tim O'Reilly's 'Intel Inside' of data. Data as core service over next 10 years. Improving use of data, navigating it, more data means better ways to manipulate it needed. Can you help users connect it together? 3. Architectural Principles. Matt Biddulph http://www.hackdiary.com/slides/xtech2005. i. Look to add value to aggregate web of data ii. Build for normal users, developers and machines iii. Start designing with data, not with pages iv. Identify your first order objects and make them addressable v. Readable reliable and hackable urls vi. Correlate with external identifier schemes (or coin a new standard) vii. Build list views and batch manipulation interfaces (3 views - destination, list view, manipulation interface) viii. Create parallel data reps using standardsAPIs, microformats, parallel XML, RSS ix. Make your data as discoverable as possible http://www.plasticbag.com

Technorati Tags: Conferences, Design, Flickr, Future, futureofwebapps, Internet, Long Tail, Media, Networks, Social Networks, Software, technology, Usability, Web

Cal Henderson of Flickr

2006-02-08T03:46:00.000-08:00

Live Notes from The Future of Web Apps Summit Flickr - Awesome, and almost 2 years old now Passionate developers create passionate users. You have to care about the things you're building. What users want and what they need are different. Many things Flickr built are not what people would have said they wanted. Ten things 1. Collaboration. Flickr started as a MM Online Game. Massively Multiplayer Online Photo Network. They kept 'friends' and removed 'enemies' feature :-) Social network from the ground up. Incentivise adding people to the network. Collaborative Metadata - adding tags to own photos but also to friends' photos. Idea of a family working together to annotate pictures that a family representative has uploaded. 2. Aggregation. Latest photos from everyone, different slices in different ways, tags, location, Interestingness algorithm (activity around photo) 3. Open APIs. Web services API. Flickr needed it for AJAX-based apps, internal use intially, then opened up later. First stage to do read-only (feeds etc) - lots of value in this alone. Beyond this RPC-type APIs turn into web services where others build interfaces onto the data. This has led to things being built that the developers would never have built. Example of multiplayer game Fastr based on tagging photos. Without an API people will still do this sort of stuff, but they'll scrape etc and it's hard to protect against the downsides of this. Bandwidth hits etc. 4. Clean APIs. Expose logical structure, not the internal workings. MOD_rewrite under Apache. Guessable URLS, and immutable: They must never change! Even when you change system you have to support old URLs too. 5. AJAX. Not necessarily JavaScript or XML.. about the Asyncronous part primarily. XMLHTTPRequest and an API to call. Strong API to expose all needed functionality is required. Used on Flickr to streamline interaction, remove page-loads, save some bandwidth, retain state and context. Also for creating whole new experiences - self-contained applications. 6. Unicode. Internationalisation (building in the functionality) and localisation (translation of relevant parts of app and data). Build in support from the beginnning, using Unicode. UTF8. 7. Desktop/Platform Integration. How can we pull interactions out into other regular apps. All based on APIs. Early on build Mac/Windows uploader apps to overcome limitations of web for doing this. Also browser apps such as bookmarklets, XUL for Mozilla, Avalon for Windows. Integration with email. People already have and understand it, simple mechanism for getting pictures into Flickr (inc mobile users), and notifications out of Flickr to email. 8. Mobile. Will one day become a more important platform.. and they still keep saying it. Simple markup standards XHTML Mobile Profile 1.0. Small apps for mobile devices which will work on majority of modern devices. Building content for mobile is different, not just skinning. Build specially for the constraints of the devices, and the context of use. 9. Open Data. RSS is useful but not a mechanism for getting all of data in and out of system. Easy escape routes are an incentive to stay. Users own their data, and the metadata that happens around them. Allowed through read/write APIs. Also a source of interesting third-party apps - eg export to DVD. 10. Open Content. Prior to Flickr web apps which stored metadata would pretty much own the data you upload. Flickr is different, and they can't do anything to/with the data without your permission. Additionally Creative Commons licences can be applied, leads to very interesting and fun reuses. All pics in presentation were CC from Flickr Slides at http://iamcal.com/talks

Technorati Tags: Conferences, Creativity, Design, Flickr, Future, futureofwebapps, Media, Networks, Social Networks, Software, technology, Usability, Web

Joshua Schachter of del.icio.us

2006-02-08T02:28:00.000-08:00

Live notes from The Future of Web Apps Summit JS is talking about what they've learned in building del.icio.us Browsers - quirks, headers, caching, lots of pain Scaling - Don't do it! Unpredictability of scale problems (this gels with what 37 Signals have said). Set up a monitoring system for out of hours problems. Selective indexing. Caching wherever possible. Latency is ok in places - figure out where this is and how much. Understand your database intimately. Abuse - Idiots are smarter than you. Wait to see what breaks before you fix it Apache - Tune, use a proxy, split up stuff between servers, throttle. APIs - JS built API early to bring data in, tech 'priesthood' need this for long-term security. Make it easy so people use it a lot. No API key in del.icio.us. Identifiers - Don't expose unique db id - prevents scraping entire database from computable ids. Features - and feature requests. Features (included and excluded) determine how people think about system. Don't duplicate features available elsewhere - messages as example of duplicating email. Get to the bottom of feature requests - why is something being asked for? Solve the problem rather than fulfill the request. RSS - everything that could have a feed should have. Understand headers, caching etc. 60% of RSS traffic is requests to see if something has updated. URLs - keep simple, don't do session ids in URLs, don't expose workings of system. Expose some functionality via URL. Surprises - watch for what people do and determine whether to amplify or supress. Passion - solve a problem you have. You will understand the problem and be passionate about things. It's inexpensive to build things, and even a niche problem is acceptable because of infrastructure for revenue, advertising. Release - Early and update often. Don't be closed and quiet. Each day behind losed doors is a lost opportunity. Attention and Attention Theft (Spam) - Cut off systems whereby people become driven by ratings and figure out how to beat system. Usefulness of error messages in people doing this.. so don't do them. Tags - Useful for recall, ok for discovery, terrible for distribution. Tags are not definitive. Motivation - why are users there? Expect selfishness. What is the payoff for the user? Make the userbase you already have want to bring people in. Measurement - intuition backed by numbers. Put numbers to everything. Measure the system itself and behaviour rather than claims. Testing - Labs or even Starbucks testing :-) Don't give them goals, tast real behaviour. Let people figure stuff out and wander off. Language - what are people calling things? Favorites vs Bookmarks. Speak their language. Registration - don't make them register before they see the site, or even use the system. What are they going to get out of registration? They have to see it, not be told it. Fear of spyware etc. Design Grammar - if it's different from the way other systems work understand where you're breaking from this. Everywhere else do exactly what the Design Grammar is and don't move far from this at all. Navigation positions, logo link to top etc. Morals - things are really purged when you delete on del.icio.us (makes API more complex, but important) Infection - vectors of word of mouth promotion. How to enable evangelism. Invade every communication stream you can. Look for viral vectors - rss, email, desktop apps which handle http etc. Community - be careful unless you're actually building a community. Communities exist elsewhere and enable them to use it without forcing them to use it. Questions for JS later.

Technorati Tags: Conferences, Creativity, Design, Future, futureofwebapps, Futurilla, Internet, Long Tail, Networks, Social Networks, technology, Usability, Web

Pricing Web Services

2005-12-09T06:47:00.000-08:00

Let's take a more detailed look at pricing options. Here's what I think we want to accomplish:

1. Neatly scaling revenue as service grows
2. Affordable and simple pricing
3. Revenue streams for client, designers, coders, resellers, futurilla

Some ideas:

Futurilla: service charge for managing portal (scale, but ideally zero - can we cut to the chase on this?), job handling commission, specialised services.
LGD: design fee, per-page design, monthly support, page redesign, site management
Designers and coders: one-off design fees (this needs to be predictable)
Clients: Adsense, PayPal, e-commerce facilities.

In conversation we've discussed the idea of a marketplace for services with pricing responsive to urgency and availability. Certainly this needs to be considered, but is outside the scope of getting things started. Predictability of costs is an issue and keeping things to small atomic units might help, both for clients and suppliers; it's harder for costs to mushroom when they're small, simple jobs priced according to time and completed rapidly. Payments too need to be small and responsive to needs: Having a web page redesigned should be as simple as buying something from eBay; and both can use PayPal.

Notes:

It's important that clients should have lots of options for updating content themselves. Note that here we're not making any assumptions about the kind of website, nor whether it's static, dynamic, blog or any combination of things. This is purely about the managing of the design work and service.

The myprotova pricing is worth revisiting. This had a free option, with a three-tier paid service (create, design, develop). I'll try to dig out the documentation and see if there's anything worth exploring there.

Technorati Tags: Creativity, Design, Employment, Futurilla, Internet, technology, Web

LGD Notes

2005-12-08T15:59:00.000-08:00

Following last night's meeting with LGD I thought I'd gather a few notes and ideas, and at the same time try out the Journler software for the first time (My initial reaction to the interface is very positive and it seems quite intuitive at this stage). LGD agreed to look at some proposals for what we have in mind, and seemed generally positive about what we were saying. I think they've moved closer to knowing they have to do something. The question now is what? We talked a lot about different pricing for web design, and about charging for more things, possibly on a subscription basis. This is certainly something to revisit at a later stage. Initially I think we need to experiment with using Basecamp for managing a web design project - possibly with Futurilla acting as host for this (though I have no desire to end up as another gatekeeper in the way their freelance web designers have tended to, it would seem churlish to not at least explore the option of hosting and managing this, and I think the reality is that they need someone to hold their hand if they're to do it at all). My objectives are:

Assist LGD in developing a model for profitable web design work which takes account of new models
Explore broader models for this in a collaborative mode
Develop the futurilla portfolio and income streams

My current ideas (which I'd like to discuss more with Mike, and with Dan too):

Open a Basecamp project for Futurilla/LGD Web Site Services (or similar)
Begin work on compiling a database of web designers/coders
Develop an LGD blog and LGD-designed template for their relaunched site
Source server space (later LGD could have own space on which to host customer sites)
Explore pricing based on per-client-month and per-item basis

Ideas for development:

Use LinkedIn to source some coders
Offer some work via Rent A Coder
Use the futurilla blog to work up ideas for developing this
Google analytics/Mint
Blogger/TypePad/Moveable Type
Backpack for client site pitches
Flickr for photo hosting
del.icio.us for link management
Blinksale for invoicing
PayPal for payments

Pricing needs special attention. LGD need to make some money, and the pricing structure should more closely match the actual costs of doing the work (ie not a single payment for continual futzing with the site). Cost for getting things online needs to be as low as possible, with basic templates and paid customisation work. Custom page designs at a per design rate (or a package). Site management on a per-month basis. We could look at the billing side of things and take a percentage, we could charge a sliding scale fee, the occasional one-off, make money on T-shirts, or anything else. I'm open to suggestions.

Technorati Tags: Birmingham UK, Design, Futurilla, Web

What is Futurilla?

2005-10-26T14:29:00.000-07:00

While we have a 'strategies' project in the wonderful Basecamp, I'd also like to open things up a little more here. The advantage of this space is of course that it's open to all. There's a part of me that would really like to open source the thinking, the strategies, and the business models (such as they are). To that end, I'll be doing some thinking aloud here, and would like to hear from others about what makes sense, what doesn't, what they'd like to do/make/acheive and ways that futurilla might be a vehicle for those aspirations. So far Futurilla has been driven by a few specific things:

My long-standing (and slow-burning) desire to find a vehicle for some of the exciting things which I've discussed with colleagues and friends, but which simply aren't going to happen through institutional channels. These include software, events, publishing projects, and stuff that just seems like it would be fun.
My initial foray into experimental podcasting; I've done some tests under the Usergland name and have started investing the time (and some cash) into the fairly small resources needed to expand this. Work has started on planning things like server space and bandwidth (the first parts are in place), and a couple of very interesting partnerships to capture and publish content are, at least verbally, agreed. This little micro-network switches to operating under the Futurilla brand as 'Futurilla Sound'.
The initial success that Mike P and I have had with writing future-oriented technology/education papers (Cyberworlds 2005 Prague, League of Worlds 2005 Melbourne, Cyberworlds 2005 Book chapter) and our desire to both expand on that in some controlled way and to develop it into other forms and areas (eg. wtdw, a personal hyperspace, and Charlotte Carey's creative enterprise.

The connecting tissue of all of this is its orientation towards the future, towards looking at things in new ways, and towards trying to figure out where we're heading. I'd like to explore ways of embedding these things into some sort of business strategy, while keeping things as loose and ad-hoc as is possible. Can it be done?

Technorati Tags: Creativity, Future, Futurilla, Media, Networks, podcasting, Open Source, technology, Transformative

Futurilla

2005-10-17T02:15:00.000-07:00

While this blog is in stealth mode (it's not listed on Technorati, though I'm sure Google will get it soon) it may be an idea to use it to develop some ideas here. Mostly they'll be in our Basecamp project, but direct ideas to do with the development of the Futurilla blog might be worked up here. My thinking is that this should be a team blog: not all of the things on our own blogs (personalhyperspace, usergland etc) or our project blogs (eg. wtdw) are appropriate here, and we'll want to post specific things here (news about futurilla as a whole, events - I'll open an Eventful calendar for futurilla associated happenings). We can easily make all "futurilla" tagged links in del.icio.us appear in a section here (either in my personal account, as with the links on Usergland, or from everyone's). We can't yet (easily) just pull in an rss feed, though I'm investigating options and suggestions are welcome.

Hello World!

2005-10-14T15:16:00.000-07:00

Test posting, please delete.