3 Technology Link |
| Posted: 13 Dec 2011 02:04 PM PST Google Currents (for iPad)
Clean, easy-to-navigate design. Offline reading. Linked YouTube videos are embedded within the page. Cross-device subscription sync. Looks sharp in both portrait and landscape modes. Free.
Long refresh times. Trending news stories don’t show publication names. Lacks Flipboard’s Facebook and Twitter social network updates. Trending News section also includes links to stories hidden behind paywalls.
The free Google Currents is a welcome addition to the iPad newsreading apps space thanks to a slick design, the ability to tap your Google Reader feed for content, native offline reading, and cross-device syncing. It has some issues?namely unidentified paywall sources, long sync times, and lack of Google Reading sync?but it’s worth a download. Flipboard (Free, 4.5 stars), Zite (Free, 4.5 stars), and a handful of other iPad newsreading apps have changed the way that we consume media, by allowing news junkies to read content in a tablet-friendly, magazine-like format. Google enters this expanding category with its own take on the mobile newsreader, Google Currents. This free iPad app (also available on Android) lets users read online publications in a slick, easy to navigate layout. Featuring partnerships with the likes of Fast Company, Forbes, Good, and many other publications, Google Currents has no shortage of interesting content. The biggest obstacle may be getting users to use it instead of the entrenched champion, Flipboard. The Reading Fundamentals I then arrived at the Google Currents home screen, an area that is divided into two sections. The upper half cycles through images that are culled from the publications in your Library (a section housing the sources to which you've subscribed) as well as Trending (a section featuring hot Google News stories). A translucent bar, which resides at the base of each image, contains the story title and RSS feed name—at least for items in your Library. Trending stories show titles, but no specific publication names which I found a bit head scratching as people have their favorite news sources that they’d like to check out. The lower half contains the full list of items in the Library and Trending areas. The Library section contains thumbnail icons of a source's official logo, but that's not always the case. Saveur Magazine, Forbes, Good, The Daily Beast, Fast Company, and 500px—the default organizations added when you log into Google Currents—have logos, but the six other sites I added (a mix of majors and indies) did not. Thankfully, Google has opened a self-service platform for publishers who want to brand and customize content. Tapping and holding a logo opens a menu that lets you rearrange the order of the Library's icons or delete a publication altogether. The Trending area displays the top five trending topics, the time when the story was added, a few of the news sources, and an image. Tapping a trending story doesn’t open the page; instead you’re shuttled to a screen that displays a larger list of related stories. I initially didn’t like the fact that I was bounced to a second screen, but after a few minutes of use, I realized that this larger list contained a wide variety of new sources, which helped me discover new outlets. Diving Into Content Another gripe: The Trending section also includes content from the likes of The Financial Times, which has its content behind a paywall. There’s no way to know whether a link is free or paid until you click it, which is frustrating. Thankfully, this was the only paywall source I encountered. So far. Navigation operates in a similar fashion as other iPad newsreading apps. You can swipe from page to page (alternately, you can hit the forward icon) or tap the menu icon that launches a sidebar table of contents that lets you quickly jump to another story. You can also share articles via email, Facebook, Twitter, Tumblr, Pinboard, and Instapaper, you can recommend the story to others by tapping “+1,” the signature mark of Google+ (Free, 3.5 stars), Google's new social network. Unlike Flipboard, Google Currents doesn’t display updates from social networks such as Facebook or Twitter, but you can view the Google+ updates from Google Currents curators such as Robert Scoble. Bringing a finger to the home screen's search icon lets you explore several categories (Featured, Recommended, Design, Sports, and more) or search for a RSS feed. You can also import Google Reader feeds into Google Currents, and your subscriptions are synchronized across all devices on which you have the app installed. Unfortunately, there’s no two-way sync between Google Reader and Google Currents. This means that if I wanted to read, say, Fast Company, in Google Reader, I’d have to add it there even if it already exists in Google Currents. This needs to be rectified ASAP. You can read Google Currents in both portrait and landscape modes—I liked the freedom here. It took over five minutes for feeds to be transformed into a readable Google Currents source (Flipboard content is ready for viewing seconds after you add a feed). I suspect that is due to the Google Currents caching the information for offline reading—something that Flipboard doesn't do unless you also have an Instapaper account. We’re awaiting confirmation from Google regarding the lengthy load times. Should You Download Google Currents? Spec Data
 Google Currents (for iPad) : EditionsGoogle Currents automatically adds a handful of publications (called “Editions”) to the home screen when you log in the first time. These news sources include the Huffington Post, GOOD Magazine, and more.  Google Currents (for iPad) : MenuTapping the menu icon opens a sidebar that lets you quickly jump to a new story without swiping through pages.  Google Currents (for iPad) : SharingGoogle Currents has a number of sharing options including Facebook, Twitter, and, naturally, Google+.  Google Currents (for iPad) : Sign InYou can sign into Google Current using your Google credentials. Currents gives you the option to import RSS feeds from Google Reader.  Google Currents (for iPad) : TrendingThe Trending area lets you view hot stories that you aren't subscribed to, which helps in discovering new news sources. (c) 2011 3tlink.info Share and Enjoy• Facebook • Twitter • LinkedIn • Digg • Delicious • StumbleUpon • Reddit • Google Buzz • FriendFeed • MySpace • Add to favorites • Email • Print • PDF | ||
| How to Win Approval on Your Design Presentation Posted: 13 Dec 2011 02:03 PM PST How to Win Approval on Your Design Presentation
One of the most common misconceptions about director/architect-level designers is they do less work (produce fewer wireframes, specifications, etc.) than junior-level designers. In fact, their work is more complex than people initially imagine when starting out in the field. You have to balance many ideas, requirements, and people, and have to make independent decisions that will cost thousands, if not hundreds of thousands, of dollars. The buck stops with you. This is a level of responsibility you have to endure, if not enjoy, to thrive in higher-level design. When I was an entry-level designer, I would be handed various interaction design problems and asked for a solution. I would then present three or four solutions to my immediate managers and be done until the next such request. I was always curious what happened after I handed it off. I came to realize that there were several more handoffs, each getting more precise and more fierce as it moved up the chain of command. Different teams would have to get involved, then team leaders, then finally stakeholders, each giving opinions on changes, personal ideas, and ways to try and cut costs. The balancing act that you must do for that is beyond the scope of this article, but I will try to help you deliver the best possible solution you can. This article is an overview of how to deliver completed designs to other teams or stakeholders in the highest levels of design. I am not going to explain details of design process, because you likely have one of your own, your team's, or your company's. I'll specifically tackle how to walk into a large meeting to present deliverables and get the best reception possible. I should also add that my experience is with large corporations, such as Microsoft and Apple. How I present ideas to colleagues may be very different than how a vendor or a design agency would present an idea. My strategies for delivering designs are meant to influence a set of peers to maintain the best possible experience for the user. Your focus should be entirely on what's best for the customer. Share Documents in AdvanceInclude all relevant documents including the specifications, executive summary, UX testing materials and, if possible, other requirements that stakeholders have given you. If they want to read before the meeting, you should facilitate that in every manner possible. Air out your dirty laundry, include links to past specs and meeting notes if applicable. The importance of this step is to help them prepare for the meeting. It's bad form or just bad judgment to introduce a new idea or direction in a large meeting without proper warning. The initial kneejerk reaction will most likely be negative. Resistance to change is inherent. It's better to give them as much preparation material as possible to facilitate a speedier meeting. You'll be able to presume understanding of the concepts or reference the materials you have sent out during the meeting with more confidence. I like to include past UX testing findings with notations. This lets me speak directly about the customers' needs when discussing solutions: "As you can see, six out of seven customers were searching for a way to do X. This pushed us to design a solution for X." Also remember at the beginning of the meeting to make sure everyone got the materials and to ask if anyone had any questions. Some examples of documents that I have given out prior to meetings:
Know Your Colleagues Be familiar with each of the personalities in the room, and why are each of them has been invited to the presentation. Determine the roles of each member and make a mental note of the history your design team has had with them. Try to anticipate what each person might challenge you with. Think through questions that each may ask and try to determine if there will be any "gotcha" moments beforehand. At Microsoft, from my recollection, approximately 50% of the employees have a title that's some variation of "program manager," or PM. This is a very general job title and can represent so many different types of roles. The PMs I usually came into contact with were software PMs, whose job is to watch the money. They keep track of the timelines, the budget, and generally keep an eye on all the different teams working on a particular feature set. They ensure everyone is working as hard as they can and that we finish on time and on budget. When presenting to a group of PMs and developers a significant change to current thinking or process, the reactions will be varied. Many things are on the minds of the participants, including timeline, amount of code, impact on the customer, impact of the footprint (memory or cycles), etc. The developers may invite the challenge of trying to come up with something ingenious to solve the problem of developing your solution, but the PMs may want to keep resource utilization to a minimum. Conversely, the developers might not want to get that deep into the code for something they see as arbitrary and unnecessary because it will have a low customer impact, while the PMs push for more "wow" moments. This is why it's important to understand where each of the meeting participants is coming from. If one of the PMs is constantly fretting about deadlines, be prepared to speak directly to how your designs will actually affect the deadline. Do Your HomeworkAre there any academic papers relevant to your designs? Have you checked ACM? Developers and PMs react positively to peer-reviewed academic papers given as support for design decisions. Being able to cite testing results or give specific examples from an academic paper is worth its weight in gold. It's also worth investigating whether there is any company history that might bear on your work if this is an ongoing version of a product with significant development history. Has this particular solution been tried before and failed? If it did fail, be prepared to speak to that history and how your solution is different and an improvement. Be specific. Have all raw notes, summaries, and findings from user testing ready to go. Be prepared to deep dive into the results as much as you need to be. Be able to cite specific testing answers if need be; more times than not, it's very useful. I have found that when PMs or developers don't want to do a particular piece of a design—perhaps because of the number of hours it will take or its perceived risk to the stability of the build—they will hammer it incessantly, challenging the thought process, the reasoning, or the design process. These concerns are easier to respond to when you have user testing results ready at hand, and have organized them in a way that anticipates how you might need to use them to respond to concerns. When you start designing a particular feature or add-on to a product, remember that you are not the first. There should be a massive amount of documentation on why the designers got to the point you are at now. If you were designing for Microsoft Office Help, for example, you would not expect to go in fresh. There is a massive amount of documentation, designs, test results, and other political/corporate decisions that went into where it lies. Before presenting some new and interesting feature or add-on, always make sure that you have researched the history behind it first. Talk to some of the senior people; do they have any recollection of that particular feature ever being introduced? Can they recall any unwritten corporate decisions, legal problems, or technical issues that led to its currently not being implemented? Research the idea or feature to the best of your ability to help prepare yourself for speaking to why it should be implemented now if it wasn't in the past. Understand the Technical and Engineering RequirementsIf you don't quite understand why engineers cannot implement a particular requirement, ask questions. Generally, you will find a dev or two who loves helping with and learning about design. It is very helpful to have an ally in the development team, someone you can confer with, bounce ideas off of, or get good development advice from. In my experience, there is always at least one developer who is more design savvy than a normal developer. Relationships with this type of person are invaluable in the design process. Feed your designs to your design-savvy developer for feedback on the complexity of implementing the designs how it would affect the product technically. Be friendly with developers. They are not your enemy (most of the time). Developers are fearful of designers' ability to create thousands of lines of code with a simple sketch. So instead of approaching your design work simply from a designer's standpoint, approach it as someone who would also have to build it. Whatever you get approved, someone is going to have to labor over to actually implement. Be precise and be exact if your aim is to get full sign-off on a design. If you don't get this detailed in your review, expect to have to do another review when you do. Do not go into a meeting and describe a "slow animation that sweeps from the left;" do go into a meeting and say, "The animation begins and lasts for 0.3 seconds, and here are four slides, from 0 to 0.1 to 0.2 to 0.3 and the resting state at 0.4." But even this isn't enough. Make sure you have talked to a developer first to see if this can even be implemented in the manner that you want it to be. Understand the overall system ramifications of your design are beyond the scope of this article, but I would suggest you gain a familiarity with all the workings of your particular application or solution have on whatever system it may be running on. This includes, but it not limited to, the variables that are changing hands, the memory load, the machine cycles, the net connections, etc. Try to understand as much as you possibly can before asking the next level of stakeholders. What is the effect on the rest of the application or experience? You don't want the entire experience to pay a tax (in whatever machination that may come in the form of) for a small feature that it shouldn't have to pay. Conducting the Meeting
At the start of the meeting, explain the goals for the meeting and what you want everyone to get from it. What you'd ideally like is universal buy-in and strong approval for your design so it can get sent to production, but if you don't get that, don't freak out. If you do get rejected, try to understand everything you can about why you got rejected. What were the specific points that supported their criticism? Can you fix them? Take critique well. Remember that arriving at a solution is not easy, especially when you're working with larger and more complex systems. You may get approval for 90% of the design, but stakeholders might request tweaks or different variations on particular details. This is the easy part. Tweak or do these variations in quantity—three or four of each—and present them to a smaller audience, sometimes only the dissenters. This should help you get to the next level. Iteration is part of the process. I have personally gone through 8-10 design iterations on a particular feature before I finally got approval. Don't think of it as 20% rejection, think of it as 80% approval! Some additional tips for running the presentation:
Always remember to do what is best for the user. You aren't there to make your colleagues happy or sad. In the end, you all have the same goal. You all want to make the customers happy and create a piece of software that you are proud of. This can be one of the hardest parts of working in the UX field. Trying to be a voice for the user's point of view in decision-making. Senior colleagues will all have their own ideas what is best, so use the user's perspective as an objective frame of reference for responding to them. Don't explain things in terms of your own opinion; rather, speak in terms of the user. Don't say, "I picked this because it was a cool design;" instead say, "We chose this design because it tested amazingly well with current/future/target customers." Closing the MeetingGo over what you have agreed upon and ensure it's clear. Give action items with dates to everyone who needs them. If someone assigns you an action item but says they need to find something first, call that out; if they don't find that something, you shouldn't be responsible for the action item. Schedule meetings immediately following other dates and action items. Your job is to get this through to production. Your job is not complete until it is. AftermathDiscuss the meeting with teammates who were not available to attend. When discussing challenges that were brought up, give them the best representation possible rather than being dismissive of them or making straw men of opposing arguments. An Unspoken TruthThis piece of advice I have saved for the end is generally not talked about in senior level/corporate design circles, but it I think one of the most crucial aspects of getting approval for a design. I think it was best said by a very respected designer and dear friend of mine (who shall remain nameless): "The best way to get a design approved is to let them think it's their idea." I cannot emphasize this enough. By leaving strategic holes in your design and allowing others to come up with conclusions or obvious fillers, it reinforces their own personal stake in the design. This will get them personally involved in the approval process as one of your biggest advocates, since they'll equate defense of your ideas with defense of their own. This whole idea is rather sketchy, so use it with caution. You will be giving up some ownership of your design, but in the end remember your goal is to make the best experience for the user. It's about them, not us. (c) 2011 3tlink.info Share and Enjoy• Facebook • Twitter • LinkedIn • Digg • Delicious • StumbleUpon • Reddit • Google Buzz • FriendFeed • MySpace • Add to favorites • Email • Print • PDF |
| You are subscribed to email updates from 3 Technology Link To stop receiving these emails, you may unsubscribe now. | Email delivery powered by Google |
| Google Inc., 20 West Kinzie, Chicago IL USA 60610 | |
No comments:
Post a Comment