Monday, October 27, 2014
Saturday, November 26, 2011
The DSS Lab runs an internship programme for coursework students to get a taste of what it's like to be an active participant in the research group. Jason Lu recently completed a project where he developed a proof of concept iOS interface for a BI reporting tool, something that we hope to be able to use to do research on mobile and touch interfaces for BI. - RobIn recent years, mobile BI has become a frequent topic of discussion among BI vendors and users, especially after the success of the iPhone and iPad since 2008. Smart phones and tablet PCs are performing an essential role in managers' daily lives, however, BI users and vendors face challenges with using and developing mobile BI applications.
One of the issues for the BI software vendors is the need to connect to a server to retrieve data every time the users attempts to generate a report. This creates a problem when using the application without a network connection, such as when flying. One area of further research may be to try an alternative that stores temporary report data locally in the iPad. However, this may present a security issue if the user loses the device.
Some other areas of future research might also include investigating user interface principles for touch such as pre-defined gestures for things like drill down and roll up.
To conclude, this internship experience offered me a great opportunity to study, in depth, some of the advantages and disadvantages of mobile BI applications on multi-touch mobile devices. In my opinion, with the tablet device, users can interact with reports more intuitively, but they face potential security and accessibility issues along with the benefits provided by the portable device.
Thursday, November 3, 2011
I'm running a web based study at the moment. I'm asking people to look at a random series of charts - created using chart styles found typically in current BI systems. Got 5 minutes to help out? Then visit http://vishnu.infotech.monash.edu.au/BIcharts
Posted by Peter O'Donnell at 2:49 PM
Tuesday, March 8, 2011
Stephen Few recently wrote a post after having attended an SAP BI presentation here in Melbourne a couple of weeks ago (unfortunately I missed it, and the chance to meet him, although a couple of colleagues from the DSS Lab did manage to catch up with him). The central thrust of his post centred on the issue of an engineering versus a design perspective on the problem of providing decision support.
I reckon he's spot on and his argument echoes a line of thought that I've been toying with for quite some time.
For myself, I've been grappling with this concept of design versus engineering as I've practised and taught IT-based design techniques like conceptual data modelling. What's fundamentally different between the two perspectives? Both engineering and design express themselves through the properties of a technical artefact. They also have a symbiotic relationship with each other - one can't do design without engineering, or vice versa. However, intuitively there is a fundamental difference of perspective, and it's taken me a couple of years of reading and thinking to put my finger on it.
The 'aha!' moment came a couple of weeks ago as I was working on a paper trying to more rigorously define the notion of Web 2.0. One of the problems with that idea is that every IT industry niche has jumped on the bandwagon so that now we have BI 2.0, ERP 2.0, even Library 2.0, without really identifying what it's fundamentally about.
My thesis is that Web 2.0 is not about the technology itself - AJAX, RoR etc. etc - because you can achieve the same Web 2.0-style outcomes using different technologies like HTML5 etc. Instead, Web 2.0 is a design concept, perhaps even a design movement. This led me, in a circuitous way, to read a paper by Lynne Markus and Mark Silver called A Foundation for the Study of IT Effects: A New Look at DeSanctis and Poole's Concepts of Structural Features and Spirit.1 In this paper, they critique an earlier theory of studying IT artefacts based on the idea that what's really important is not so much the features of a given piece of technology, but rather the relationship between that technology and its users.
For example, they draw on the concept of affordance. This relates to the things that an object or environment offers an actor, but it's specific to each actor. While a chair might be something that offers me the affordance of sitting, to a child it is an object that can be climbed on, crawled under, and so on. In other words, to understand a technological artefact, we have to look, not so much at the artefact itself, but how the properties of the artefact and the properties of the user interact.
And this was that aha! insight: the difference between design and engineering is that design is concerned with the space between the user and the artefact; engineers, on the other hand, are primarily concerned with the artefact itself. Both express themselves through the properties of the artefact itself, but design treats that as secondary to what the artefact does for the user, what it means, and how it impacts on the environment.
The problem with vendors in BI, and really most of the IT industry in general, is that we're all focussed on the technical artefact. As a result, the design of how that artefact is used, what it allows users to do, and the impact that it has on the decision support environment is largely ignored. As Stephen Few points out, old-school, large-scale BI vendors are so focussed on their software's bells and whistles that they almost completely ignore the fundamentals of helping people make more effective, better quality decisions.
Following from Markus and Silver's paper, I'd argue that design of IT artefacts, including BI software, needs to consider two key concepts: affordance, as described above, and what they call 'symbollic expressions.' The latter refers to the implicit values, principles and ideas communicated by the technology to the user. Too often in BI, the values and principles that are communicated by tools like Crystal Xcelsius, and lots of dashboard implementations, is form over substance. Dazzling your audience with 3D exploding pie charts and speed-dials is given more importance than imparting a proper understanding of the relevant information.
It's time that we had a design company in Business Intelligence, rather than the plethora of engineering companies we now have. Think Apple versus IBM. Love or hate them, there is no denying that Apple's focus is on the experience of using their products within an ecosystem of iTunes, App Store and iDevice, rather than on the technical attributes of the devices themselves. From a technical standpoint, Apple's devices are not significantly better (and they're often worse) than their competitor's products. But it's the design that goes into the experience of using the device that makes the fundamental difference. IBM, on the other hand, is the classic engineering company focussed primarily on the technical artefact itself.
We need a vendor to do for BI what Apple did for music players, mobile phones and tablet computing. We need a vendor that understands tactical and strategic decision making in organisations and who is willing to have a go at changing and improving that process rather than bolting on yet another suite of 'smoke and mirrors' to their already bloated software.
1 Markus, M. L. and M. S. Silver (2008) "A Foundation for the Study of IT Effects: A New Look at DeSanctis and Poole's Concepts of Structural Features and Spirit," Journal of the Association for Information Systems (9) 10/11, pp. 609-632.
Friday, February 11, 2011
Thursday, December 16, 2010
Just a quick update. Been a hard couple of semesters for us all keeping us busy, making it hard to get our research done, and even harder to get time to blog. However, we have had a bit of a reboot as a group and are now all busy pursuing our research agendas over the Australian summer break and hope to get a bit of time to blog in the next few weeks and months, and hopefully do a better job of blogging more regularly when teaching starts again at the end of the first quarter next year. There have been some significant organisational changes for us, we wound up our Centre and reconstituted our "Lab". Our hope is this will make us more agile - like we once were - one concrete change in the short term has been the establishment of our lab web site at http://dsslab.infotech.monash.edu.au. Nice place holder site there at the moment but that site will grow. It will also be the base we use for web applications and experiments so stay tuned for posts featuring calls for participation that involve using applications hosted at that URL. It will also be the URL to visit to get copies of reports and working papers.
Posted by Peter O'Donnell at 9:55 AM
Thursday, March 25, 2010
This is the third of three posts looking at the details of a functional framework for Web 2.0 / social media. The earlier posts are:
The final category in our social media framework deals with contributions to the social media platform itself. One of the key ideas in O'Reilly's explanation of Web 2.0 is the adoption of lightweight, flexible development methodologies that rely on the active involvement of the community of users to build the platform. Intuitively this makes sense: the usage of a particular social media platform shifts and changes over time as community members use the technology for a variety of real-world purposes. Users stretch and pull the features of a particular platform: think of the conventions that have built up on Twitter: the use of the @user reply format or integration of Twitpic, TinyURL and other similar tools - none of which featured in the original design spec for the Twitter platform.
Platforms that don't adapt and change go into decline. MySpace, for example, is burning a US$580 million hole in Rupert Murchoch's pocket in part because News Corp didn't understand the need to allow the platform to evolve and change in a free and flexible manner. Decreased usage of that platform can be attributed to an increased emphasis on advertising (leading to a crappy user experience) and a glacial bureaucratic process for the implementation of design changes.
Involving the community in the development of a social media platform is an example of utilising the wisdom of the crowds, again a key component of O'Reilly's explanation of Web 2.0. A social media platform is more than just the site itself, but also includes the 'ecosystem' of related applications and support sites that allow the community to use the site for a variety of purposes. This means that there are two different ways in which the community of users of a social media platform can contribute to the platform itself:
- Contributing to the platform design
- Contributing to the ecosystem of applications around the platform.
Clearly the former is more common than the latter, and takes the form of both explicit and implicit feedback. Often, the developers of a platform will directly engage with the community to find out how they want to use the platform, looking for ideas for new features. Frequently, though, the feedback takes the form of a change of usage pattern. As users try to use the platform in unanticipated ways, developers respond by either making it easier to use existing features (eg. embedding @replies into the structure of the Twitter platform) or introducing brand new features (eg. the ability to geotag photographs on Flickr).
Very occasionally, a user of a platform will develop a 3rd party application to introduce some feature not directly supported by the platform, or to allow a customised means of interacting with the platform. The plethora of Twitter applications for devices like the iPhone is an example of this, as well as the image, video and link applications that extend the functionality of the basic platform: hardly anyone uses the web interface as their primary means of using Twitter. Sometimes the 3rd party applications end up being integrated into the platform itself (see the Twitter search tool which started as an independent web app), but even if that doesn't happen, the platform is extended and supported by this 3rd party ecosystem, leading to a wider range of uses and appealing to a larger group of users. The easier it is to develop a 3rd party application (through technologies like XML, SOAP or even plain old HTML APIs) the richer this ecosystem will be.