I’m still not sure what to do for my five potential catalogue images. These are the ideas I have so far; opinions or recommendations welcome.
May 3, 2011
May 2, 2011
PRP Artefact 3: Review
My third artefact set out to discover differences between two major types of interactivity within digital magazine formats. The two formats researched for this artefact were ‘static’ and ‘interactive’. After having discovered the most preferable method to build a digital publication in my second artefact, I thought it important to discover what type of interactivity provides the most preferable user experience.
To perform this research I created two digital publications, one using each of the methods. Both of the productions contained exactly the same information as a means of keeping a fair experiment. A focus group was then presented with both of the publications to read and explore. They were then presented with a questionnaire to gain their feedback and thoughts of each of the different publications.
The results of the questionnaire were almost identical throughout; the main questions were all answered with five out of six people preferring the interactive method, and one person the static.
My major concern about using an interactive system was that some information may be ‘lost’ to a user if they have to do something to trigger its appearance. As a result, a final question was added to the questionnaire to see if the users felt that this may be an issue. One person said that they thought it did cause some information to be lost, one was unsure, and four people did not feel it was a problem.
This experiment proved that despite some potential problems, an interactive magazine format is by far the most popular option for digital magazine publications. In my fourth artefact I intend to discover what aesthetic properties attribute to a successful digital publication.
March 11, 2011
March 9, 2011
PRP: Artefact 3; Concept Development
After my splurged article yesterday regarding my initial thoughts for my third artefact, I have had some more ideas and guidance from my tutor on where to take the development.
I have agreed with my tutor that I will focus artefact three on understanding the visual communication implications of an interactive magazine article compared to a simple static magazine conversion. Both of which would be designed for use on a tablet device.
The main purpose behind this is to see if having an interactive magazine article can cause the content to loose some of its impact by concealing some of its information that can only be accessed via interactive means.
To put that in simple terms; ‘Static Article v Interactive Article: Which provides the content in the most preferable method’.
So now my task is to go and create a very ‘static’ article, and a very ‘interactive’ article, and pitch them against each other using a focus group.
In order to keep the results as fair as possible I intend to use entirely the same article information in both versions, so the only variable, is how it is accessed. This is with the possible exception of some sort of explanation as to how to use the interactive article, after all I’m not interesting in testing peoples pre-expectations of tablet devices, and intended to design the interactive article intuitively as possible.
In order to know what kind of article to produce, I need to know if any lend themselves to contain interactive elements, as simply ‘showing more content on-tap’ isn’t really revolutionary or helpful in the user-experience.
To help me decide what type of article to start with I have compiled a list of all the ‘types’ of articles I could find whilst trawling through several magazine publications. I have also compiled a list of all the ‘types’ of magazine interactions I could find that are currently used in interactive tablet magazines.
The Article Types:
- Cover Page
- Featured Articles/Contents
- Advert
- Generic Text and Few Images
- Interview/Q&A
- Multiple Reviews/Comparisons (Products, Services etc.)
- Large Feature Article (Different Text Areas, Many Images, Quotes, Multiple Pages)
- Gallery: More or equal images w/text
- Profile (people, businesses, products)
- Tutorial
The Interactivity Types
- Scroll down for more content
- Jump from contents page to article
- Click to play video
- Tap to open link (external web page)
- Tap to reveal more content in current page
- Rotate for more content
- Rotate for video
- Rotate for image gallery
- Tap to change a section of content (Like mini-options within a page)
- Rotate for interactive environment experience
- Tap for next page
- Double tap to exit away
- Integrated website
As I intend to keep the delivered content identical for both versions, there are a number of the interactive methods that are unsuitable.
My refined list of possible methods of interactivity are:
- Scroll down for more content
- Jump from contents page to article
- Tap to reveal more content in current page
- Rotate for more content
- Rotate for image gallery
- Tap to change a section of content (Like mini-options within a page)
- Tap for next page
- Double tap to exit away
Although this excludes some of the more interesting capabilities that digital magazines could provider, I feel keeping the test as fair as possible to be of great importance to this project.
The final step before thinking about design and production is to establish what type of article I will create. The decision process for this will take in to account what type is most susceptible to have interactive elements used within it, and which of those is most time efficient, as I am accountable to deadlines and do not have a particularly long time to spend producing the articles.
After some careful deliberation, I believe the best type of articles for this are; generic text and images, interview and large feature article. Due to the nature of the artefacts, I have decided to reject the idea of an interview as it may be difficult to formulate an interview with an individual that all members of the focus group can relate to. That leaves generic text and images and large feature article, as they are very much the same thing (one being more complicated than the other), I have decided to build an article, and will let the overall length and complexity of it determine which category is suits best.
When it comes to designing, I intend to change the look of these articles from those that I had previously created for this project. Although elements of the designs may stay, I will now focus the design toward magazine-style publishing layouts. I will use the iPad edition of WIRED magazine, and the print editions on .net magazine as inspiration for my designs as I feel these two publications best reflect design that is appropriate for digital publishing.
PRP: Artefact 3; Ideas
So, I’ve just sent a fairly long email to my tutor regarding my ideas for my third artefact. I must apologise again for this, but I do seem to wrap my head around my ideas better when I transcribe them. Something I’ve recently discovered.
So, quick re-cap. Artefact one showed that people still prefer using paper as a medium on which to consume published media, they rejected interest in using either a laptop or a mobile smartphone as ever being a useful medium in which to consume published media, however they did generally agree that they may be swayed toward using a tablet device for consuming the media if the media had been produced specifically for the platform. As a result of this, artefact two took the information that people were only really interested in using the tablet, along side a prominent argument that featured in my original thesis that there are two key methods of developing a platform/mobile specific design; ‘mobile specific’ and ‘responsive’ design techniques. Artefact two document the build process of both design methods and concluded that responsive design was superior throughout for an endless number of reasons.
After doing some thinking about where to take my third artefact, I am wondering if I should step back from the responsive design conclusion I came to in artefact two, and focus on my original question. My research question is; ‘How is the evolution of publishing modes providing new visual communication opportunities within online and mobile environments?’
To start looking for ‘new’ visual communication opportunities I’ve been thinking about what features are available on a tablet, which are not available elsewhere. The obvious difference between traditional publications and those that appear on a tablet is that it is possible to make the tablet edition provide the content in a more interactive and user experience-driven way.
Despite this, my experience of magazines on tablet devices has showed me that they still tend to be static page versions which are ‘zoomable’ and maybe the occasional link to a website. The exceptions tend to be tech-driven magazines. WIRED magazine being a fantastic example.
I would like to focus artefact three on how a ‘static’ magazine page on a tablet compares to an ‘interactive’ page, which contains the same information, but utilises the interactive elements of a tablet to view and access the information in different ways. I would then show the concepts to a number of interviewees to gain an understanding of which is preferable, and more importantly if the interactive version has provided a preferable method of delivering published content using new visual communication opportunities provided by tablet computing.
I’ve got this fairly well planned out in my head now, so am just hoping my tutor agrees with the concept. I’ll be back later to provide details of more specific ideas and how the concepts would work.
March 3, 2011
PRP: Artefact 2; Review
I’ve finally got to the end of my artefact two experiment. For information of the introduction, mobile site development and responsive design development, please check my previous posts.
This artefact was set out to discover the high and low points of both developing mobile specific and responsive design alternatives.
Mobile Specific Design:
The mobile specific design had multiple low and high points to it’s production and final outcome:
The positives:
- Very quick to implement for a single site alternative
- No prior knowledge needed
The negatives:
- No adaptation for how device is being used
- Forced to compromise on design decisions due to previous comment
- Takes up more space
- End result is no drastically better than original site view
- Would have to do many more versions to cover all devices
Responsive Design:
The responsive design took longer to initiate, but also has it’s ups and downs:
The positive:
- End result is brilliant
- Can adapt to how device is used
- Takes up small amount of extra space
- Would take little work to work on many devices
The negatives:
- Some prior knowledge required
After summing everything up, I think it is fairly obvious that for the most part, responsive design is superior. The only thing I will say about this is that many people say that “well, mobile specific designs could be made to adapt to orientation etc if you used the queries” and this is true. However, if you were to go to the effort of sorting out the fiddly bits of getting queries to work how you’d like them to, it would be much more efficient to just create a responsive design as opposed to making multiple sites for the same device.
Just to give everyone an idea of what these sites now look like, here you go:
The regular ‘desktop’ site:
The mobile specific design:
Responsive design in landscape:
The responsive design in portrait:
PRP: Artefact 2; Responsive Design
Ok, so this is just a blog post for documenting my progress of my responsive design conversion for my second PRP artefact. Please check out my Artefact 2 explanation and the mobile specific design posts for more information of what, why and when I’m doing this.
So just to reitterate the old posts really briefly; I will be making a responsive site as an evolution of a fairly standard web page and recording the experience from design, build, production and end product as a part of my second artefact. I have done the same thing already making a mobile tablet specific site. I intend to pitch the information against each other as a method of understand the issues presented by both methods of producing mobile-savvy sites and which, if either, is a superior production method, and why.
Update 1: I’ve opened up my original website and taking a look at the fairly static code, it’s clear I need to get back to basics in terms of site fluidity to get this to even start to be mobile friendly. I think I’ll go through the site, changing all the fix widths with min’s and max’s depending on how that particular element needs to fit in a page. I’ll make a start with that and see how it goes.
Update 2: After going through my stylesheet to change all of my widths to be flexible where possible, it is pretty obvious already that this method takes a lot longer to do initially. Anyone that’s every played around with websites will know that a fluid-width design, when transformed from a fixed-width design, will look somewhat different. After having completed the basic fluid CSS changes, the site looks pretty much the same as it did before, just being slightly wider or shorter in extreme circumstances. This should set me in good stead for getting it to work well on the iPad. After a first glimpse of this on the iPad, its obvious that this is currently still plagued with the same problem as the mobile version, and that is the font size. However this time I will go about tackling it using media queries, and not simply trying to find a ‘happy medium’.
Update 3: Media queries are impressive. There’s no doubt about it. Yes the concept and implementation is actually really simple. But just doing it for yourself helps you to understand and appreciate how much of a step forward this is for CSS. It took me about 10-15 minutes to find some documentation of CSS3 Media Queries and how to go about focusing them toward an iPad. After about a further 60 minutes (40 of which were spent arguing with a single box that I’d forgotten to stop the float on) I had completed my iPad portrait-mode layout. Which if I hadn’t been a bit silly with that box, is really quite fast! Granted the page isn’t very complicated anyway, but still, it’s no long, drawn-out process. I’m really pleased with the way it’s going so far, and will post what the site looks like in my conclusive post (probably the one after this one). I will now go and do the same for the landscape orientation =)
Update 4: I’ve now completed the landscape version, this only took about 20 minutes as having a screen 1024px wide is not dissimilar to some small computers, so less work had to be done to make it look ‘right’. The only problem that I had in this with the original HTML source was that of the integrated YouTube video, and was the same problem that I experienced in making the mobile specific website. However having changed the code to the old YouTube method, it now works well on the iPad and has not affected the desktop version what so ever.
Conclusions: Already I’m overly convinced that responsive design is so much better than simply providing a mobile alternative. The site looks endlessly better in the iPad in both portrait and landscape modes, as well as remaining almost untouched in the regular ‘desktop’ view.
Please see my following post for a full review of the artefact and how all the views compare to one another.
March 2, 2011
PRP: Artefact 2; Mobile Specific Design
Ok, so I’m using the blog post as a way of documenting my thoughts on the construction of my mobile specific design.
As I mentioned in my previous post, I will build both my mobile site and my responsive site by starting from a generic website view as a starting point instead of designing and souly separate sites as this is a very common way of converting existing publications.
Update 1: Ok, so my first thoughts on doing this are WOW that’s fast. So, again referring to my previous post; you have to remember I’m only doing this to adapt to a tablet (iPad specifically) due to the findings of my first artefact. So I imagine that it would take significantly longer to do this for a mobile version. And you would have to do it for multiple mobile platforms, tablet, smartphone, regular phone, other portable devices etc to get this to look good on ‘every’ device. It’s taken about 20 minutes to adapt this to an iPad specific version. I’ve been using http://ipadpeek.com to test the site on my local server, however because the resolution on my screen (amongst other things) are not identical to the iPad, I suspect I will have to make further changes after testing it on my iPad. The site is being uploaded here: http://www.tom-edson.co.uk/prp/a2/mobile/ so feel free to test it out on your own iPad, I will now test it and see how well it has gone.
Update 2: I’ve just taken a look at what the site looks like on the iPad and few things spring to mind immediately. The first is that, the text looks much smaller than it was intended. Although it is still proportionally larger than it is on the standard web version. This may well just be the difference between fonts rendered on a Windows machine (the one I’m coding on) and that of the iOS system running on the iPad, so the next step is to keep testing different font sizes until I find something I’m happy with.
The second issue raised by this initial viewing is to do with the variable ways the content can be viewed on the iPad. Because the iPad can be used in vertical and horizontal alignments, the content simply shrinks and expands to fit either orientation and max-width. The only way to solve this would be to introduce media queries in to the style sheets to change styles depending on the orientation of the device. I am reluctant to introduce these as they are very much the core principal behind the responsive version of this site which voids the purpose of comparing both development methods.
The third and final issue relates to the video used in one of the articles. The video used in the standard website uses YouTube’s latest and standard method of embedding their video in to other websites. This method appears to not allow the iPad to access any controls once the video has started, not even to stop the video from play, as well as having no full-screen capability. Although the video plays to a satisfactory level, it would be a fairly major flaw for a publication that intended to utilise a large amount of video, I intend to try and fix this problem if possible within the constraints of creating the mobile specific design.
Update 3: As the font size is a highly important part of the design process, I have decided to change the font sizing system from using strict px sizes and use em sizing instead. Although em sizing is ‘variable’, I am using a fixed ‘standard’ font-size, as such is not responsive to it’s viewing medium.
While having changed the font sizing system has made it easier to change the relative font sizes to find ones that appear suitable for the device, it still suffers from the orientation problem. When in portrait mode, the text is readable, although a little small, and would require some zoom from the user to enjoy for a duration of reading. When in landscape mode the text is easily readable, but certainly couldn’t be made any larger without appearing too large or childish. I felt this is the best compromise for both views so will leave the text as-is for this version of the site.
I have now tackled the issues regarding the YouTube video. I am unsure why the latest version of the YouTube embed functionality is lacking iPad/tablet support, however the fix for this was as simple as using their old embed code (which they still supply) within the code. Although this is an easy fix, it could potentially cause issues where third parties upload content to a design. This could be solved through a multitude of ways, including media queries, which I cannot use in this version of my site, or by forcing the use of the old API through PHP queries. The use of PHP queries would be acceptable in my mobile specific design, but cannot be executed within the size restraints of this development.
Update 4: After a few simple sizing tweeks to the CSS I am now happy with how my mobile specific site comes across on my iPad and will not be making any more changes.
Conclusions: This method of making a mobile savy version of a publication is certainly a very quick and easy method of doing so. I transferred, what in reality is a very simple one-page website in to a mobile alternative in the period of 1-to-2 hours including having to seek out bug fixes and trial-and-error experiments with CSS alterations.
Although this method is undoubtedly efficient in this instances, it must be reiterated that to get a result that is this focused toward a particular device the process would have to be repeated over and over before all appropriate device types are covered, which could take some time given how many similar devices are already available. This method of development would also require constant updates if support for new devices is required.
The thing that really brings down this method of development for me is how even on the same device, the overall experience of the site can be damaged simply by the way in which the user chooses to hold their machine. Although it will be argued that this could be easily resolved by the use of media queries, this goes against the purpose of this experiment and would only be accepted in a hybrid of the two aforementioned development types.
