Mobile Project Management
2 likes806 views
The document discusses best practices for mobile application development and management. It covers the project life cycle, including initiating, planning, executing, monitoring and controlling, and closing a project. It also discusses managing enterprise mobility through a holistic approach, common challenges such as scheduling concerns, and best practices for use scenarios, prototypes, user interfaces, store submission, and testing. The overall focus is on effective strategies for developing and managing successful mobile applications and projects.
Mobile Project Management
- 1. What does it take to convert information into productivity? Mobile Project Management Bringing business into context Sébastien BRISON
- 2. Agenda
- 3. Life Cycle
- 4. 5 core processes • Initiating • Planning • Executing • Monitoring & controlling • Closing
- 5. Software Project Management Life Cycle
- 7. Managing enterprise mobility • How can companies insure an approach in a holistic, unified fashion? • Businesses in the US and UK are making average current investments of $422K • A third of companies are planning to launch four or more mobile projects in the next 12-18 months • The companies are working with several mobile solutions vendors due to the inability of suppliers to address multiple mobile value chain aspects. Antenna’s Mobile Business Forecast 2012
- 8. The lack of a holistic approach • Mobile solutions suppliers today are mostly small specialist providers • Large companies are forced to commission multiple projects in order to multiple strategy sections • Companies take over six months to complete projects, with 10 percent taking a year or more to finish them • Mobile strategies have become fragmented, redundant, and the projects have ended up being difficult to manage. Antenna’s Mobile Business Forecast 2012
- 9. Scheduling concerns • The devices take more time to set up for development and testing • There is a learning curve for adjusting to new tools and hardware versions • A surprising amount of time can be lost if devices aren't available • People get tired and uncomfortable more quickly using mobile devices • Multiple store submission requirements also are quite time consuming
- 10. Use scenarios
- 11. Scenarios Use scenario is another name for a particular flow of events. A use case covers a range of situations – a scenario is just one. Each use case typically has: – Current state describing the traditional flow – Future state describing the “ideal path” – alternate flows describing major exceptions Several alternatives exist for specifying the use case scenarios.
- 12. Describing Scenarios Textually Write text to describe the interaction of the actor(s) and the system. Simple and easy approach May be limiting: – Numerous alternate flows make it hard to understand where normal flow can branch. – Long alternate flows need to be broken out as steps too. • Use Case: Checks out item 1. Customer sets item on counter. 2. Sales clerk swipes UPC reader across UPC code on item. 3. System looks up UPC code in database procuring item description and price. 4. System emits audible beep. 5. System announces item description and price over voice output. 6. System adds price and item type to current invoice. 7. System adds price to correct tax subtotal. • Error case 1: UPC code unreadable • If after step 2, the UPC code was invalid or was not properly read, emit an audible „bonk‟ sound. • Error case 2: No item in database • If after step 3 no database entry is found for the UPC flash the „manual entry‟ button on the terminal. Accept key entry of price and tax code from Sales Clerk. Set Item description to “Unknown item”. Go to step 4.
- 13. Describing Scenarios Graphically Create an Activity Diagram to graphically show the interaction of the actor(s) and the system. Create a Sequence Diagram to graphically show the interaction of the actor(s) and the system Easy to slip into too much detail Great start for design activities
- 14. Mock up
- 15. Paper Prototype • Paper + Pen • Metal Stencil http://www.uistencils.com/iphone- stencil-kit/ http://appsketchbook.com/ Payant
- 16. Paper Prototype • Paper + Pen http://speckyboy.com/2010/11/18/ultim ate-collection-of-printable-mobile- sketching-templates/ Download
- 20. Ipad Version Prototype • iMockup
- 21. User Interface
- 22. The importance of the user interface
- 23. Design and Usability Interface • Design and Usability of the App is the key for success • Provide a clear and clean layout - users have to use your app from the very first beginning without any help • Users should not think about your app at any time, they should simply use it
- 24. « Great » User Interface • follows human interface design principles, that are based on the way people think and work, not on the capibilities of the device. • Methaphors (playback control, sliding on-off switching, ...) • Direct Manipulation (with the Multi-Touch Interface) • See and Point (Presenting choices or options in list form) • Feedback (must be immediate) • User Control (user, not the application must initiate and control actions)
- 25. Build in Simplicty/Ease of Use • Users are probably doing other things while they simultaneously use your application • Make it obvious • High level Information near the top of the screen (independent of how people tap on screen, top is most visible) • Minimize text input • Keep essential information succinctly • Provide a fingertip-size target area for all tappable elements (calculator example: 44*44 pixel)
- 26. Focus on the Primary Task • An iPhone Application that establishes and maintains focus on its primary functionality is satisfying and enjoyable to use“ • What is most important in each context? • Is the provided information essential, does a user need this information right now?
- 27. Communicate Effectively • „ ... avoid technical jargon in the user interface“ • Feedback is important • Use user-centric terminology
- 29. Starting iPhone Application should start instantly so users can begin using them without delay • Specify appropriate status bar styles • Display a launch image • Avoid displaying an About window, splash screen or another type of startup experiences • Launch using the portrait orientation
- 30. Stopping • iphone Applications should never quit pogrammatically • Be prepared to receive an exit or terminate notification at any time. • Save the current state when stopping • Avoid alerts • User has to decide if continuing you application or pressing the Home Button
- 31. Settings and Configuration • It„s best when iPhone application do not aks users to specify any settings at all • Focus your solutions on the needs of 80 percent of users • Get as much information as possible from other sources • If you must ask for setup-information, prompt users to enter within your application • Offer configuration options in the main user interface or on the back of a screen
- 32. Settings and Configuration • Don„t provide a button for a built-in action, because users will wonder why there are two ways to do the same thing in your application“ • Support Copy and Paste • Support Undo and Redo • Enabling Push Notifications (delivery is not guaranteed) • Providing Search and Displaying Search Results • Using the User„s Location
- 33. Using Sound • Ring/Silent Switch (avoid sound if it is not explicity set) • Volume Buttons (the user always decided the loudness) • Headset and Headphones (plug in headsets means sound has to be set privately) • Wireless audio (disconnection = pause, connection = no pause) • Defining the Audio Behavior is essential task
- 34. Main parts of an application screen • Every application, regardless of type, has an application window • Status Bar • Navigation Bar • Tab Bar • Toolbar
- 35. Different Application Controls • Remember that users expect familiar controls to behave as they to in the built-in applications
- 36. System Provided Buttons • promote a consistent user experience and make your job easier.
- 39. Size of screens • Dimension
- 40. Main Transitions - 1
- 41. Main Transitions - 2
- 42. Main Transitions – 3
- 43. 6 - STORE SUBMISSION
- 44. Store submission process - 1 • 1. Add Device Program Portal • 2. Xcode Organizer
- 45. Store submission process - 2 • 3. Create Developer Certificate • 4. Add to Keychain
- 46. Store submission process - 3 • 5. Create Apple ID • 6. Create Provisioning Profile
- 47. Store submission process - 4 • 7. Add Provisioning Profile to Xcode Organizer • 8. Test Code .
- 48. Applications Submission Check List • Name of the application • Application Icons • Text Description • Category • Launch screen • Copyright, SKU number and keywords • URL • EULA
- 49. Name of the Application • Application name 255 characters • Must be unique • Be careful using off limit terms: aka Google Mail program could cause a rejection.
- 50. Application Icons • Branding and strong visual design should come together into a compact, instantly recognizable, attractive package“ • Create different sizes of your application icon for different devices • The Icon is must be seen as branding of the app - the first contact of the user with your product
- 52. Text Description • Make a good description of you app in few words • Think carefully about keywords - users will search for them and you never can change them • 4000 character limit 700 characters is recommend Plain text only section headers and bullet lists make it easy to read
- 53. Category • Where your app is found • Don‟t get too cute. This can cause you to lose downloads and sales. • Category Choices: • Business Education Entertainment • Finance • Games • Healthcare & Fitness • Lifestyle • Medical • Music • Navigation • News
- 54. Launch screen • Provide good and impressive screenshots • Give the user the feeling your app is quick and fast • Help the user to get familar with your app • 1 screenshot required - 320 pixel x 480 pixel • 4 additional screenshots optional
- 55. Coppyright, SKU number and keywords • Copyright • Year • Company name • Rights reserved • SKU Number • Made up number • Keywords • 100 character, comma-separated list • Be specific • No offensive words • Don‟t use other app names
- 56. URL • Application URL • URL to webpage with more details about application • Tip: a good one pager will suffice • Good example website: http://taptaptap.com/ #parablox • Support URL • URL to webpage with contact details for support
- 57. End User Licensing Agreement • This is optional. • Apple will use a default EULA if you don‟t include one. • You may have an attorney draft a custom EULA here to include for you company.
- 58. Quality testing • Which Smartphone ? • Which Context ? • Which Objectives ? • Which scenari ? • Which features? • Int or ext test? • Testing Plan • Bugs report
- 59. Testing plan • Introduce the project • State the goals of the test • Profile your desired test subjects • Create a test subject screener • Outline your testing methodology • Define your tasks • Write a testing script • Design a post test survey
- 60. External testing
- 61. Key Points
- 62. Control the scope • A good app is the best technical solution for the target group • Define the scope : device compatibility and the OS • Ensure that scope does not affect external environmental factors
- 63. Measure the need for change • Measure on how the aera will be impacted • Measure the technical knowledge of the client to avoid scope creep • Measure the change expected by the client • Go step by step
- 64. Measure the risk • New uses = New risks
- 65. Criteria • Time • Cost • Earned value management (EVM) is a project management technique for measuring project progress in an objective manner, with a combination of measuring scope, schedule, and cost in a single integrated system.
- 66. The communication plan • Provide an own website for you product • Think about a carefully Social Media Strategy (Twitter, Facebook, Blogs ...) • Essential Question: How can you reach your users that they get aware of your app • Provide a light version of you app