Ok, I thought this would be an interesting quick blog...over the years, I've worked in environments where the nomenclature of your dept or group was ever changing or just plain unknown. Let's face it, we love to rename everything in society to meet the latest craze. I've been in db development, production, engineering, software Dev...am I a project manager or a producer? In the visual design and graphics space, I'd be a Producer, managing a team of designers performing the work. Since output is visual in nature, I'm considered a Producer of said artifacts, not entirely correct, but in the Hollywood sense, I suppose I would be equal to a Producer of your fav tv show, the guy behind the scenes pushing and pulling, bringing the thing alive. Since I believe Project Management is a set of tools, this feels good to me. Using PM methodologies, I lead an effort to produce the work.
As a shop specializing in delivering UI/UX software solutions, your Project Manager becomes a UX Producer, a user experience producer by trade. That sounds pretty prestigious, just don't let it go to your head if you're in that bucket;). Heck, you get to be famous with you friends if only for a few moments in time. Next step, a Star on Hollywood Blv...
2008-10-17
2008-10-15
Utilizing resources in different ways in XAML driven gigs
As a Project or Resource Manager, you're often faced with a reoccurring dilemma in UX driven projects - that of putting the time in to clearly define dynamic styles, screen transitions, control initiation/dismissal, button styles, etc. Don't forget to plan for this in the workload - ideally, you get time from your information architect to depict logical wireframes that make up the UI and identify the use case(s) that need to be satisfied with the solution, and you've got the creative team working to produce design compositions depicting look/feel of the various screen elements and its backdrop. Even better, you set in motion your creative designer and information architect, or BA, to put together a clickthrough slide deck that describes the flow of the application - this can just be a simple PowerPoint deck where you drop in the comps and provide the "Arlo Guthrie" effect (I call it) where the circles and arrows and a light paragraph describes how the app will support the wireframes and use cases...OK, so big deal, you say...let's jump into implementation, right? I've got my pile of approved comps and I've got data to work with, let's go.
Wrong! My point of this post is to simply remind you that there's a crucial step missing if we set engineering in motion from this point. We need to loosely define the expectations of each page transition - how should the screen transition when called...when dismissed? How about the controls that will be needed? How do we expect the controls to be spawned? What's the feel of the app? What's the target audience of the app? What's the target resolution for the app? Loads of questions should be asked here to assure that we put some creative thoughts into how such transitions and styles could be employed. Really, there is no right or wrong answer, but some thoughts should be gathered for each dynamic element of the app in the form of a bullet list of text. I've been calling this motion architecture - we need to describe the motion of the visual elements in some way using human words that help a Design Integrator implement a solution to solve each demand.
OK, so how does this align with the title of this post? Cool, you're paying attention...take advantage of many of your resources - you don't need to find your Expression Blend person and say, make it hot! Consider the designer who can do some motion modeling in his tool of choice - don't ask for an implemented solution here, we're merely searching for that new look, the new sleek metaphor that hasn't been abused elsewhere recently. Or consider engaging a resource skilled in hand drawn art to sketch out some cool ways to motion graphics on the screen. The key here is that these are all concepts, ideas that feed discussion. Your Blend resource can recreate what the team finds cool into a storyboard or transform or something that can be really cool. SP1's shaders - cool OOTB visual effects ready to go in the platform for WPF projects - are another option. As the app framework comes together and the pages get stitched, you've also stirred another sense - that of personality. If the app is fun, make it sharp, crisp, and provide a style for everything consistent with this theme that you're evolving at this point. Don't make a hodge podge of effects either into the app since that completely abuses this privilege, but making these decisions up front and consistently in the project sets a good tone for your project team and reminds them that everyone can contribute here, and nothing should be rejected. This goes for the QA team as well - hitting the app during component testing may surface some cool ideas. Get it all documented and kept as an Addendum to the slide deck I describe above.
Wrong! My point of this post is to simply remind you that there's a crucial step missing if we set engineering in motion from this point. We need to loosely define the expectations of each page transition - how should the screen transition when called...when dismissed? How about the controls that will be needed? How do we expect the controls to be spawned? What's the feel of the app? What's the target audience of the app? What's the target resolution for the app? Loads of questions should be asked here to assure that we put some creative thoughts into how such transitions and styles could be employed. Really, there is no right or wrong answer, but some thoughts should be gathered for each dynamic element of the app in the form of a bullet list of text. I've been calling this motion architecture - we need to describe the motion of the visual elements in some way using human words that help a Design Integrator implement a solution to solve each demand.
OK, so how does this align with the title of this post? Cool, you're paying attention...take advantage of many of your resources - you don't need to find your Expression Blend person and say, make it hot! Consider the designer who can do some motion modeling in his tool of choice - don't ask for an implemented solution here, we're merely searching for that new look, the new sleek metaphor that hasn't been abused elsewhere recently. Or consider engaging a resource skilled in hand drawn art to sketch out some cool ways to motion graphics on the screen. The key here is that these are all concepts, ideas that feed discussion. Your Blend resource can recreate what the team finds cool into a storyboard or transform or something that can be really cool. SP1's shaders - cool OOTB visual effects ready to go in the platform for WPF projects - are another option. As the app framework comes together and the pages get stitched, you've also stirred another sense - that of personality. If the app is fun, make it sharp, crisp, and provide a style for everything consistent with this theme that you're evolving at this point. Don't make a hodge podge of effects either into the app since that completely abuses this privilege, but making these decisions up front and consistently in the project sets a good tone for your project team and reminds them that everyone can contribute here, and nothing should be rejected. This goes for the QA team as well - hitting the app during component testing may surface some cool ideas. Get it all documented and kept as an Addendum to the slide deck I describe above.
Subscribe to:
Posts (Atom)