This topic is of huge interest to me, because sadly, I will confess now that ... I ... am ... a ... mobile information addict.
There, I said it! I'm not ashamed to make such an admission, but part of me wishes I could turn back time to a period of my earlier life where I was able to blissfully wander this earth without having access of all kinds of useful and useless information at my fingertips, where ever I was. Life was so much simpler back then!
Ask just about anyone these days to produce their phone on the spot, and you'll gather that most people will have a smart phone, which is essentially a small computer with internet connectivity, with, oh yeah! ... a phone built in. You can surf the WWW, check your emails, download music, movies, ringtones and install all kind of useful software applications which in some way aim to improve your life, or find ways to distract you from it!
Speaking from experience, I use this device more for the smart (capabilities) than the phone (function), although I carry with me and use that latter function more as a security which I value above my superficial needs to check what all my friends are up to on Facebook.
The main issue faced by the (hardware) architects of these devices, and subsequently by the software programmers presently, is the hurdle of providing access to services and programmes on mobile devices that were initially designed as desktop applications for larger computers and laptops, which have larger memory, more processing power and bigger displays than their new, smaller relatives.
Mobile devices are also context sensitive (i.e. they know where they are) and the integration of GPS technology in them is now standard. It allows for interactivity through applications that utilise measurements of longitude and latitude to provide localised information relevant to the user on the move, orientation of the device itself to translate the mobile user's kinetic movement of the device and camera/imaging recognition through the use of a built-in camera. They also utilise Bluetooth technology to communicate with other mobile devices by sharing small amounts of data.
An excellent example of a mobile application that I use which demonstrates all these capabilities is 'Nearest Tube' on the iPhone. It is an 'augmented reality' app which uses the camera to give you a view of your surroundings through the device's screen. Transposed on top of that real time image is layered data indicating your position relative to that of the nearest tube station. By holding the phone and rotating the angle of the lens, the position of the fixed location markers change to indicate whether you are moving closer or further away to them. This is functional to the user as it acts an interactive visual compass that they can follow to reach a destination providing only the information that need to know in order to achieve that objective (i.e. their position, the position of the tube station, the distance and the direction between the two places.)
In order to facilitate the mobility of information from static workstations (desktop PCs) to 'on-the-go' devices (smart phones), a preliminary evaluation of user information needs has to take place. We need to assess what information is available to the users, determine is the most valuable or desired information the user will want to know or access (the core data) and keep it, putting to the one side the less valued information or be disposing of it altogether. Finally we take the core data and build functionality around it in order to display it to the user using the most effective means. All subsidiary information is concertinaed to make it less visible and prominent but still accessible should the user wish to use it.
This is where we can revisit the idea of APIs and mash-ups, as a workable solution to this information-reducing conundrum. The idea is to extract only the core data and build an interface around it on the platform which optimises the visibility and prominence of that information, all the while being aware of the limits or constraints of that platform. For example, software plug-ins such as Flash, Javascript or Shockwave which embed interactive moving animations into web pages consume computing resources and are therefore not suitable, or compatible, with smaller processors. Access such a web page from your smart phone, for example, and an 'error/incompatibility' message appears in place of the plug-in. Access denied. Website owners, be it the press, business or even individuals without commercial intent, are wise to this, and at the risk of alienating a large market of mobile internet users who will visit their sites to read information, have developed mobile versions of their sites. The objective of such sites is go back to the basics in providing key information with no thrills - a diluted version of their full site which places accessibility over content in terms of assessing the user's needs. Functionality is used as the tool to bridge the gap between the two, as in essence you can have the best of both worlds.
A good mobile site, for example, provides clear navigation to the heavily used functions of that site, such as news stories, images or maps, timetables or calculators which all provide some practical immediate use to the user. The data involved here should be anything considered so important that the user should not have to spend any time searching for its location. It should be prominent and grab the reader's attention within a matter of seconds. Anything that is exploratory (i.e. information which is supplementary in nature, requires more time to digest or is too large to condense) can be hidden away under a concertinaed menu, or in a smaller font, off to the side for example. This allows for access, but the user will have to specifically search for it if they want to access it. The underlying focus here is on conveying content using a minimalist design.
A good mobile application takes the data from a website and imports it for use on the mobile device platform, accessed through an interface designed to harness the power and limitations of that platform, in order to present the data in the more relevant and consumable form. The approach is remove any white space or any unessential features of the website/information, and make the available (limited) screen space as functional as possible by filling it with large clear buttons and fonts that present the data as information which is spoon-fed to the user. The use of virtual, context sensitive keyboards which understand what type of data-input is required in order to access or manipulate the information is an intuitive step forward (such as months and years to select a date, figures for inputting a telephone number, or a special symbols such as @ or [.com] when typing an email). Touch screen 'gestures' such as swipe to move between documents, pinch bigger or smaller to zoom in and out also aid navigation on a small screen by reducing the need to scroll further along or down a page in order to access the pre-existing navigation functions of the site.
The practical exercise for this topic asked us to design a mobile application to support our learning in this subject. This is already available as a web resource (Moodle) which, admittedly, has been very well designed as a learning portal. The task therefore seems to ask how we could effectively make Moodle mobile ... a Moobile application :-)
The user is a student, and their information need is that they want to find out the basic amount of information to see them through a day at University. They want to know what lectures they have to attend, what subject or topic will be covered in the lecture, what reading to do in conjunction with the lecture, receive messages about their course that are relevant, such as changes to the timetable, coursework submission deadlines etc.
A mobile application would take into account all of these needs - by presenting a clear, simple interface that provides the user localised information on that particular day: an upcoming events box with three events, be it their lectures or social club activities that they have booked into, that updates over time and is therefore fresh and dynamic. A window to the Moodle subject area should also be prominent, that is context and time sensitive thus presenting a link to read the next lecture notes before and during its allotted time. A portal displaying the last 5 emails received on their University accounts, and a separate portal linked into their library account showing the number of books they have taken out, when the next loan is due to be returned and when loan requests that available to collect, together with fines that have been incurred. All other user account information is concertinaed under drop down menus at the bottom of the screen, that links to the full website version of the relevant web pages.
These are just a few ideas, but ones that this user will happily consume on the move. I just need to remember the necessity to switch-off the desire to access information in my pocket when there is not a social or immediate need for it!
Tuesday 15 November 2011
Thursday 10 November 2011
The best mash-up I've ever heard.
Following from my lengthy DITA write-up earlier in the week-up, I forgot to mention my favourite mash-up song!
Here it is. A collision of 39 songs!
Enjoy:
Here it is. A collision of 39 songs!
Enjoy:
Tuesday 8 November 2011
DITA - Understanding Blog No. 5 & 6 - Web 2.0, Web Services and APIs
I have decided to consolidate my learning on the first two topics of the second half of the DITA module, as they seem to interlink quite nicely. Explaining how the Web 2.0 technologies work, then describing the methods by which they provide information as a service to users via the internet, and finally looking at the interfaces (APIs) created to mask the internal complexities of the client systems underneath to make the information personalized to the user will be my main focus.
Its only human nature to be nosy. We spend our waking hours actively locating and investigating information about the world, other people and sometimes about ourselves! The most accessible portal for doing this is undeniably now the internet, a powerhouse of interconnected data networks, sprinkled with services and applications that essentially hand us the information we seek if we know how to find it or where to find it.
Web 2.0 was the term coined in 2005 to describe the emergence of ICTs being used to provide online services that allow the user to collaborate with other users across the same network. Traditionally the internet has been catergorised by the server-client model by which requests for data are made, received and sent back with a definite start (the client request made to the server) and a definite end (the server response received by the client). Web 2.0 effectively turns this on its head, whereby the clients, no longer statically content or restricted on waiting to receive another's generated answers, are now empowered by technology to pro-actively create and send their own data, rapidly and at will. The clients become the servers: the internet becomes the system platform; the server computers become the access point rather than the facilitator.
The online world truly becomes a global social network.
Web 2.0 applications have consumed our daily lives: they are addictive, often gluttonous in terms of data access, rapidly evolving and rapidly updating according to our needs and whims. We have now more social places to 'hang out' online, either by killing our own time (YouTube, Wikipedia) or be using our time to informally engage with others (Twitter, Facebook). Proximity and time is never an issue when we can access these places on the go using mobile devices.
All these Web 2.0 applications feel inclusive as they give us the choice as to whether we engage or spectate - create our own new data to cast-off, or swim in the same sea of other people's data. The choice is ours because it is now in our hands - technologies have become cheaper and quicker to produce and maintain, which enables us to post updates, share photos and write own our website without any technical knowledge or skill required on our part. It creates a rich user experience without any of stresses involved in understanding how to make it work. It is open and available to all, although again the choice as to whether we involve ourselves is subjective, the choice determined by own own ethical, moral and political sensibilities.
The Web 2.0 applications (such as the very blog I am typing) are all examples of web services. They are in essence computer software applications that have been installed 'on the internet', as opposed to the local hard-drive contained in your laptop/PC. In a similar vein, the data created through a new blog entry, a tweet or a facebook status update isn't saved or stored on your PC, it floats in limbo somewhere on the internet until such point when we ask to access it. We can access this data from any location that has internet connectivity. Cloud computing appears to be the next big thing, what with Google (Googledocs) and Apple (iCloud) offer cloud services to their users.
In his lecture notes, Richard Butterworth sets out a concise definition for web services, by distinguishing it from a web page:
A web page is a way of transferring information over the internet which is primarily aimed to be read by humans.
A web service, in contrast, is a way of transferring information over the internet which is primarily aimed to be read by machines.
So in essence, a web service uses web technology to pass information around the internet that is readable by machines. It is in the form of a 'language' that computers read and process in accordance with the metatags that are assigned to the data therein. The information pushed around is content only: there are no structure or presentation instrcutions included. Computers do not know or understand the meaning behind text: they can't distinguish between different parts of data as text unless there is some explicit instruction in the programming code they receive that 'label' the text accordingly as having some different meaning. Computers don't know the different between the titles and authors of some work: we as humans do though!
Web services are not intended expected to be the user end point. They are the means by which we send machine-readable data to client PCs, who then reprocess it and make it more appropriate and accessible to the user.
The programming code for a web service is XML (eXtensible Mark-Up Language). It provides, as a set of machine-readable instructions, the core data marked up with metadata (via metags) to clearly give a value or worth ("name", "price", "location" etc.) that can be interpreted by a number of other machine systems, which then display the data in the correct context, albeit in different parameters.
A good example of this would be Facebook. The positioning and level of information that are visible to the user when logged in through a computer terminal will be different (fuller, due to the optimisation of space and function provided by internet browsers and plugins) than for the same page accessed through a different machine (a tablet, or smart phone for example).
XML allows us to manipulate data to describe it in the form of your choice. Facebook understand they can't replicate the exact same layout on a web browser and on say an iPhone, so they create a new interface (an app) for the platform they wish to deliver their service to, to enable the same data in the XML code to be reproduced in the most efficient way on that platform.
This is an example of an API (Application Programming Interface). Think of using the analogy of a car: You don't need to know what's under the bonnet of your car in order to drive it!
It allows programmers to build an external shell (such as a mobile phone application), compatible with the XML code, without being concerned with how the complicated internal workings of the system underneath actually works. Programmers build upon the functionality of existing web services by creating add-ons that slot into the DNA of the service and allow users to interact in innovative or progressive ways. Examples of APIs are widgets that you can write into HTML code, and effectively place a portal to another part or service on the internet. A Twitter feed box that updates with your tweets as you send them, a button under a news story allowing you to 'like' that story and publish it on your facebook profile, or a Google map box which reproduces a section of map and marks your business/office location to enable a website visitor to find you. I have just described and examples of some of the combinations of web services with APIs, which allow for interesting mash-ups to be created in the online community. Advanced programming language such as Javascript in your web browser makes allow for this level of web service manipulation. As part of the practical lab exercise, I set up a page and included some APIs into the HTML code. Click here to see some of the examples explained above!
The same old dangers seemingly lurk under the surface however: the amount of information going online needs moderation and control, permanence and integrity of data is compromised. How data is stored, accessed and retrieved, and the reasons behind these activities are highly contentious, controversial and potentially damaging. How we classify, order and regulate the information we create, by creating metadata such as tag clouds and folksonomies, is loose and imprecise if there are no existing guidelines to follow, and leads to misinterpretations and cyber squabbles over use in context, if we don't agree on it. Web 2.0 threatens to engulf our lives and identities if we allow such technologies to define us as a society.
Final thought: the real danger appears to be that we don't know the extent of how much of our personal data is held on the internet. We may never get to see it all ... we only see whatever they want us to see!
Its only human nature to be nosy. We spend our waking hours actively locating and investigating information about the world, other people and sometimes about ourselves! The most accessible portal for doing this is undeniably now the internet, a powerhouse of interconnected data networks, sprinkled with services and applications that essentially hand us the information we seek if we know how to find it or where to find it.
Web 2.0 was the term coined in 2005 to describe the emergence of ICTs being used to provide online services that allow the user to collaborate with other users across the same network. Traditionally the internet has been catergorised by the server-client model by which requests for data are made, received and sent back with a definite start (the client request made to the server) and a definite end (the server response received by the client). Web 2.0 effectively turns this on its head, whereby the clients, no longer statically content or restricted on waiting to receive another's generated answers, are now empowered by technology to pro-actively create and send their own data, rapidly and at will. The clients become the servers: the internet becomes the system platform; the server computers become the access point rather than the facilitator.
The online world truly becomes a global social network.
Web 2.0 applications have consumed our daily lives: they are addictive, often gluttonous in terms of data access, rapidly evolving and rapidly updating according to our needs and whims. We have now more social places to 'hang out' online, either by killing our own time (YouTube, Wikipedia) or be using our time to informally engage with others (Twitter, Facebook). Proximity and time is never an issue when we can access these places on the go using mobile devices.
All these Web 2.0 applications feel inclusive as they give us the choice as to whether we engage or spectate - create our own new data to cast-off, or swim in the same sea of other people's data. The choice is ours because it is now in our hands - technologies have become cheaper and quicker to produce and maintain, which enables us to post updates, share photos and write own our website without any technical knowledge or skill required on our part. It creates a rich user experience without any of stresses involved in understanding how to make it work. It is open and available to all, although again the choice as to whether we involve ourselves is subjective, the choice determined by own own ethical, moral and political sensibilities.
The Web 2.0 applications (such as the very blog I am typing) are all examples of web services. They are in essence computer software applications that have been installed 'on the internet', as opposed to the local hard-drive contained in your laptop/PC. In a similar vein, the data created through a new blog entry, a tweet or a facebook status update isn't saved or stored on your PC, it floats in limbo somewhere on the internet until such point when we ask to access it. We can access this data from any location that has internet connectivity. Cloud computing appears to be the next big thing, what with Google (Googledocs) and Apple (iCloud) offer cloud services to their users.
In his lecture notes, Richard Butterworth sets out a concise definition for web services, by distinguishing it from a web page:
A web page is a way of transferring information over the internet which is primarily aimed to be read by humans.
A web service, in contrast, is a way of transferring information over the internet which is primarily aimed to be read by machines.
So in essence, a web service uses web technology to pass information around the internet that is readable by machines. It is in the form of a 'language' that computers read and process in accordance with the metatags that are assigned to the data therein. The information pushed around is content only: there are no structure or presentation instrcutions included. Computers do not know or understand the meaning behind text: they can't distinguish between different parts of data as text unless there is some explicit instruction in the programming code they receive that 'label' the text accordingly as having some different meaning. Computers don't know the different between the titles and authors of some work: we as humans do though!
Web services are not intended expected to be the user end point. They are the means by which we send machine-readable data to client PCs, who then reprocess it and make it more appropriate and accessible to the user.
The programming code for a web service is XML (eXtensible Mark-Up Language). It provides, as a set of machine-readable instructions, the core data marked up with metadata (via metags) to clearly give a value or worth ("name", "price", "location" etc.) that can be interpreted by a number of other machine systems, which then display the data in the correct context, albeit in different parameters.
A good example of this would be Facebook. The positioning and level of information that are visible to the user when logged in through a computer terminal will be different (fuller, due to the optimisation of space and function provided by internet browsers and plugins) than for the same page accessed through a different machine (a tablet, or smart phone for example).
XML allows us to manipulate data to describe it in the form of your choice. Facebook understand they can't replicate the exact same layout on a web browser and on say an iPhone, so they create a new interface (an app) for the platform they wish to deliver their service to, to enable the same data in the XML code to be reproduced in the most efficient way on that platform.
This is an example of an API (Application Programming Interface). Think of using the analogy of a car: You don't need to know what's under the bonnet of your car in order to drive it!
It allows programmers to build an external shell (such as a mobile phone application), compatible with the XML code, without being concerned with how the complicated internal workings of the system underneath actually works. Programmers build upon the functionality of existing web services by creating add-ons that slot into the DNA of the service and allow users to interact in innovative or progressive ways. Examples of APIs are widgets that you can write into HTML code, and effectively place a portal to another part or service on the internet. A Twitter feed box that updates with your tweets as you send them, a button under a news story allowing you to 'like' that story and publish it on your facebook profile, or a Google map box which reproduces a section of map and marks your business/office location to enable a website visitor to find you. I have just described and examples of some of the combinations of web services with APIs, which allow for interesting mash-ups to be created in the online community. Advanced programming language such as Javascript in your web browser makes allow for this level of web service manipulation. As part of the practical lab exercise, I set up a page and included some APIs into the HTML code. Click here to see some of the examples explained above!
The same old dangers seemingly lurk under the surface however: the amount of information going online needs moderation and control, permanence and integrity of data is compromised. How data is stored, accessed and retrieved, and the reasons behind these activities are highly contentious, controversial and potentially damaging. How we classify, order and regulate the information we create, by creating metadata such as tag clouds and folksonomies, is loose and imprecise if there are no existing guidelines to follow, and leads to misinterpretations and cyber squabbles over use in context, if we don't agree on it. Web 2.0 threatens to engulf our lives and identities if we allow such technologies to define us as a society.
Final thought: the real danger appears to be that we don't know the extent of how much of our personal data is held on the internet. We may never get to see it all ... we only see whatever they want us to see!
Subscribe to:
Posts (Atom)