Recomendados
Mais conteúdo relacionado
Destaque
Destaque (19)
Semelhante a Contracts & Extensions: allargare i confini della propria applicazione (Win8@work)
Semelhante a Contracts & Extensions: allargare i confini della propria applicazione (Win8@work) (20)
Contracts & Extensions: allargare i confini della propria applicazione (Win8@work)
- 1. Contracts & Extensions: allargare i confini della propria applicazione Giorgio Di Nardo blogs.ugidotnet.org/akelitz giorgio.dinardo@domusdotnet.org @akelitz
- 3. Agenda Contracts & Extensions L’uovo di colombo o la scoperta dall’acqua fredda? Search Scatena il segugio che c’è in te! Share Scopri perchè in Windows 8 1+1>2 Settings Tutte le impostazioni al posto giusto
- 4. Contracts & Extensions: cioè? Contracts Accordo tra due app per fornire e consumare uno dei servizi previsti in Windows 8 Definisce i requisiti che le due app devono soddisfare per interagire tra loro Extensions Accordo tra un app e Windows 8 Consente di estendere e personalizzare le funzionalità base di Windows 8 nella propria app
- 5. Contracts & Extensions: quali? Contracts Extensions Cached file updater Account picture provider File picker Background tasks Play To Camera settings Search Contact picker Settings File activation Share Game Explorer Print task settings Protocol activation SSL/certificates
- 6. Search: il punto di vista dell’utente Scatena il segugio che c’è in te! Demo
- 7. Search: obiettivi Far apparire l’app tra quelle che supportano la ricerca nello charm Search Effettuare la ricerca sia quando l’app è aperta che quando è chiusa Mostrare i suggerimenti e tenere traccia dello storico …
- 8. Search: il punto di vista dello sviluppatore Scatena il segugio che c’è in te! Demo
- 9. Come implementare la ricerca Utilizzate lo charm Search per consentire agli utenti di cercare nel contenuto dell’app Se la ricerca è un prerequisto per l’uso dell’app, aggiungete un’icona di ricerca nell’app Se la ricerca è lo scopo principale dell’app e volete fornire suggerimenti approfonditi, aggiungete una UI di ricerca personalizzata
- 10. Come non implementare la ricerca Se la ricerca non è lo scopo principale della propria app, non aggiungete una UI di ricerca nell’app In ogni caso non mettete la UI di ricerca nell’App Bar Non utilizzate lo charm Search per aggiungere funzionalità di “find-in-page" alla vostra app
- 11. Linee guida per la UX: query suggestion Fornite sempre query suggestion per velocizzare la ricerca degli utenti I query suggestion dovrebbero contenere il testo parziale inserito dall’utente I query suggestion dovrebbero riflettere i risultati che l’app può fornire Se l’utente seleziona un query suggestion, caricate direttamente la pagina dei risultati relativi al query suggestion selezionato
- 12. Linee guida per la UX: result suggestions Se volete suggerire un risultato preciso e ben definito, fornite un result suggestion Un result suggestion consiste in un’immagine, un titolo e una breve descrizione Se l’utente seleziona un result suggestion, caricate direttamente il dettaglio del result suggestion selezionato, senza passare per la pagina con i risultati della ricerca
- 13. Linee guida per la UX: suggestion & placeholder Fornite al massimo 5 suggestion, lo charm non ne mostrerà di più in ogni caso Non usate le suggestion per filtrare o definire il campo di applicazione dei risultati Per chiarire all’utente che tipo di testo può inserire, usate un placeholder per il campo di ricerca dello charm Search
- 14. Linee guida per la UX: risultati Mostrate all’utente il testo ricercato Evitate di mettere risultati rilevanti vicino al bordo destro dello schermo Consentite all’utente di filtrare i risultati Evidenziate il motivo per cui un particolare elemento è incluso nei risultati Consentite all’utente di tornare alla pagina precedente ai risultati della ricerca
- 15. Linee guida per la UX: type-to-search Abilitate il type-to-search Nella pagina principale dell’app Nella pagina che mostra i risultati della ricerca Disabilitatelo in tutti i casi in cui possa creare confusione per l’utente Quando sulla pagina ci sono input box Quando la pagina implementa il find-in-page Quando la pagina presenta dati ristretti ad un certo ambito
- 16. Rispondere all’attivazione per Search Assicuratevi di gestire appropriatamente la ricerca per un testo vuoto Salvate lo stato precedente all’attivazione dell’app per Search Prestate attenzione al passaggio dallo stato Snapped al FullScreen in fase di attivazione Salvate risultati e filtri dell’ultima ricerca in caso di una successiva chiamata identica
- 17. Share: il punto di vista dell’utente Scopri perchè in Windows 8 1+1>2 Demo
- 18. Share: la matematica di Windows 8 Mail Foto News Twitter
- 19. Share: come funziona Source App Share Broker Target App Registra l’evento L’utente seleziona Share: In fase di installazione si DataRequested del L’evento DataRequested registra come Share Target DataTransferManager viene inviato all’app attiva attraverso la dichiarazione nel manifest Riceve l’evento Filtra la lista delle Target DataRequested e riempie Apps e dei QuickLinks il relativo DataPackage L’utente seleziona la Target Viene attivata per lo sharing App o il QuickLink Attiva la Target App in Elabora il contenuto del modalità shareTarget DataPackage Memorizza l’eventuale Comunica il completamento Il DataPackage vive nel QuickLink resituito dall’app dell’operazione contesto della Source App
- 20. Share: cosa condividere La chiave per condividere contenuti è nel DataPackage esposto dal DataTransferManager È possibile condividere: Un testo Un link (Uri) Un contenuto formattato (HTML) Uno o più file (StorageItems) Un immagine (Bitmap) Più immagini (StorageItems)
- 21. Share: il punto di vista del programmatore Scopri perchè in Windows 8 1+1>2 Demo
- 22. Linee guida per lo Share: Source Quando possibile aggiungete il link alla versione online del contenuto locale Rispettate la selezione fatta dall’utente Usate le proprietà del DataPackage per corredare il pacchetto di informazioni utili Comunicate all’utente quando e perchè lo Share non è possibile Non serve se l’app non supporta affatto lo Share
- 23. Linee guida per lo Share: Source Non fornite alternative per invocare lo Share Conservate la selezione dell’utente Fornite un testo che indichi all’utente quale sia il contenuto dello Share Supportate lo Share dei dati copiati negli appunti
- 24. Linee guida per lo Share: Target Mantenete l’interazione semplice Evitate la navigazione per quanto possibile Non usate il light dismiss nella vostra UI Mettete i comandi fondamentali dove possano essere raggiunti facilmente Eliminate i link non correlati allo Share Se realizzate preview, fateli accurati Usate i QuickLinks con giudizio
- 25. Settings: il punto di vista dell’utente Tutte le impostazioni al posto giusto Demo
- 26. Settings: il punto di vista del programmatore Tutte le impostazioni al posto giusto Demo
- 27. Linee guida per i Settings Usate lo charm Settings per tutte le impostazioni dell’app Se necessario, fornite un collegamento programmatico diretto allo charm o ad una specifica categoria di impostazioni Usate il numero di impostazioni strettamente necessario e raggruppatele in non più di 4 per categorie
- 28. Linee guida per i Settings: quando? Usate i Settings per mostrare e modificare: Impostazioni relative all’intera app che vengono modificate occasionalmente Informazioni sull’app richieste raramente (privacy policy, help, numero di versione, copyright, ecc.) Non usate i Settings per modificare parametri fondamentali nell’uso dell’app: Scegliere il colore del pennello in un’app di
- 29. Linee guida per i Settings: Flyouts Possono essere grandi (646px) o piccoli (346px), non di altre misure Lo sfondo dell’intestazione dovrebbe essere lo stesso dell’app Start Tile Usate sezioni, paragrafi ed etichette per chiarire la gerarchia delle impostazioni Usate etichette semplici e chiare per i controlli
- 30. Come non implementare i Settings Non usate i Settings per comandi associati al normale uso dell’app: usate la App Bar Non usate gli entry point dello charm per invoca direttamente comandi senza UI Non usate i Settings per navigare l’app: usate la App Bar Non usate la classe SettingsFlyout per la UI che non sia invocata dallo charm Settings
Notas do Editor
- Rely on the Search charm to let users search for content in your app.You can and should rely on the Search charm instead of creating search-specific UI to search your app's content.Windows ranks apps listed in the Search charm based on how often those apps are searched. The more often users search your app through the Search charm the better your app's rank and position in the list of searchable apps. Additionally, Windows automatically tracks the user's search history with your app if they enter queries through the Search charm.Regardless of where your app's content is located (on the local file system, or through a web service), you can use the Search charm to respond to users' queries and display search results in an app page of your own design.When a user selects the Search charm, a search pane opens with a search box (where they can enter a query) and a list of searchable apps, as shown in the screen shot. If your app is the main app on screen, it is automatically highlighted in the list of apps in the search pane. For example, Apps is highlighted in the screen shot.If users need search to get started using your app, consider adding a search icon to your app canvas.A prominent search icon gives users a strong visual cue that tells them where to begin. When users select the icon your app should open the Search charm programmatically so that users can enter their query using the search pane. Using the Search charm in this way helps make your app more intuitive and helps keep your app's search experience consistent with search in Windows 8 and other apps.For example, a reference app like a thesaurus or encyclopedia is likely to emphasize search. Typically, when users open apps like these they want to search for information about a specific topic or word. Having a search icon prominently displayed on the app canvas in apps like an encyclopedia or thesaurus helps to ensure that users know how to get started searching for information.If search is the primary purpose of your app and you want to show extensive suggestions, consider adding a search box to your app canvas.A prominent search box helps indicate to users that your app specializes in search. When users enter a query, you can use your own custom layouts to display a greater number of more detailed suggestions on your app canvas. If your app requires more depth and flexibility for displaying suggestions than what is available through the Search charm, consider adding a search box to your app canvas.For example, the only purpose of the Bing app is to search. The app differentiates itself from other search-based apps by using custom layouts to display detailed search suggestions and interactions. Because the Bing app is entirely based on search and provides deep, variable suggestions, the app adds a search box to its app canvas, as you can see in the screen shot.However, adding search UI to your app also has disadvantages that you should consider. For example, if you provide an in-app search box, the user might have two different search histories for your app: one history tied to the in-app search box and another tied to the Search charm. Additionally, searches performed using your in-app search box (or other search UI) won't increase your app's rank and visibility in the search pane.If you decide to add a search box to your app canvas, use these guidelines to help you maintain consistency between your search box and the search pane:If the user updates the query in your app's search box, use trySetQueryText to set the query in the search pane to the new query.If the user clears the query in your app's search box, use trySetQueryText to clear the query in the Search charm by setting it to an empty string.If your app is snapped, don't update the query in the search pane. When your app is not the main app on screen the search pane can't be opened and calls to trySetQueryText don't work.If the search pane is open, grey-out or hide your app's search box to prevent confusing the user with multiple search boxes. You can see one way to apply this guideline in the Bing search app.
- If search is not the primary purpose of your app, don't add search UI to your app.If users search your app from in-app UI, your app’s rank in the list of apps could suffer making your app less visible to users. Additionally, Windows will not track users' search history for searches performed using in-app search UI.Don’t place search UI in the app bar.Maintain the app bar as a place to show commands that are unique and specific to your app. Many app developers want to provide a search experience for users, and integrating with the Search charm (by participating in the Search contract) is a great way to do this.Don’t use the Search charm to add a "find-in-page" feature to your app.When using "find-in-page", users want to stay on the current app page, but the Search charm will navigate them away, replacing the current page with another app page that displays search results.Instead, add a control to your app bar that lets users "find-in-page" and group the "find-in-page" feature with related features like "replace".
- When the user selects the Search charm and starts typing a query into the search box, search suggestions are shown just below the box in the search pane. These suggestions are supplied by the main app on screen if it has implemented the Search contract.There are two types of suggestions an app can provide: query suggestions and result suggestions.Query suggestions are auto-completions of the user's query text, and provide queries that the user might want to search for. For example, in the screen shot the user entered the query "word" and the "Wordament HD" and "WordPress.com" queries were suggested. If the user selects one of these query suggestions, the Store app will take the user to a search results page for that query.Result suggestions are strong or exact or matches to the user's query that the user may want to view immediately. For example, in the screen shot the Wordament app was suggested as a result (under the Recommendations label) for the "word" query. If the user selects the Wordament result suggestion, the Store app will take the user directly to the Wordament app page in the Store.In the screen shot of the search pane, the Store app provides two query suggestions and one result suggestion for the user's query, "word".Always provide query suggestions to help the user search quickly.Use query suggestions as way to auto-complete query text that users can search for in your app. This is a great way to help users search quickly by reducing the amount of typing needed to complete a search. Instead of entering the entire query, users can select one of the suggested queries and immediately execute the search.Your query suggestions should contain the user's current query text.Because your query suggestions should be auto-completions that are based on the current query text, they should actually contain the current query text. For example, the suggested queries provided by the Weather app in the screen shot all contain the current query text, "f".Your query suggestions should directly reflect the results that your app can provide.By reflecting the results your app can provide, your query suggestions can help the user figure out what they can search for in your app. For example, the Weather app in the screen shot automatically completes the user's query to suggest cities for which the app can provide weather reports.If the user selects a query suggestion, immediately take the user to a search results page for the selected query.
- If you want to recommend strong or exact matches for the user's query, provide result suggestions.Use result suggestions to let the user go directly to the details of a particular result without the need to navigate to a search results page. A result suggestion should consist of an appropriate image or thumbnail, a relevant title or label, and a brief description.The image, title, and description help the user to determine quickly whether the suggested result is what they were searching for, as shown in the screen shot. If you want to supply multiple result suggestions, use labeled separators to help users distinguish between results.For example, when you provide more than one suggestion for results with different content types (like movies vs. TV shows), use labeled separators to provide a meaningful distinction between the content types.Separators can be added to the list of suggestions that your app supplies to the search pane, but each separator counts towards the five-suggestion limit.If the user selects a result suggestion, immediately take the user to the details of that result without first taking them to a search results page.If you provide both types of search suggestions (queries and results), you should provide only one result suggestion and it should be displayed last, at the bottom of the list of suggestions. While the user enters a search query, Windows automatically provides suggestions for possible queries in the search pane. These suggestions are based on the user’s search history with your app and will be shown first, before suggestions that your app provides. Showing your suggested result last helps visually distinguish it from suggested queries, as shown in the screen shot.
- Supply no more than five search suggestions.The search pane will show only the first five suggestions (for queries and/or results) that are supplied by your app.Don’t use suggestions to filter or scope search results for your app.Filtering and scoping options should be placed with the results in the app's search results page, where they can refine the search results. In contrast, suggestions should be placed in the search pane, because they are directly related to the query text that the user enters.Use placeholder text in the search box to describe what users can search for in your app.Placeholder text is shown only when the search box is empty and is cleared if the user starts typing into the box. We recommend that you set the placeholder text of the search box to a brief description of the searchable content in your app. For example, a music app that supports searching by album name, song name, or artist name should set the placeholder text to be: "Album, artist, or song name".
- When the user submits a search query to your app, they see a page that shows search results for the query. Because you design the search results page for your app, you can ensure that the results presented to your user are useful and have an appropriate layout. For example, the screen shot shows the search results page created for the Contoso app, which displays example search results for the "item" query.Let users see what they searched for (their query text).For example, in the Contoso app's search results page, the "Results for" string next to the "Contoso" app name indicates that the current set of results is for the "item" query.Use a list view control and Search contract templates to bring the Windows 8 look and feel to your app. Using a list view (or grid view) control to display search results helps produce a consistent and predictable user experience and will reinforce what users have already learned in the system. The Microsoft Visual Studio Express 2012 for Windows 8 templates for the Search contract include a list view control.For C#/C++/VB, the ListView and GridView controls let you use a list or grid layout, respectively (see Quickstart: Adding ListView and GridView controls).For JavaScript, the listView control lets you use either a grid layout or a list layout (see Quickstart: Adding a listView).Search results are ranked and typically have a strong order from best match to weakest. You should order the search results on your page based on this search rank. Because grid layouts in Windows 8 use horizontal scrolling, search results that are displayed in a grid layout should be ordered first from top to bottom and then from left to right. Because list layouts use vertical scrolling, search results that are displayed in a list layout should be ordered from top to bottom.Avoid putting important or relevant results or information on the right edge of the screen.The Search charm is lightweight and quickly gets out of the way whenever the user interacts with the app canvas. However, to help users quickly glance at results, avoid showing the most important or relevant result on the right side, as this side might be temporarily covered up when the search pane is visible.Let users filter and/or scope search results from the search results page.You can improve your app's search results page by letting users set filters and scopes to refine the set of search results.Best practices for letting users filter and scope search results in your app's search results page include:Indicate the number of results available with each filter or in each scope. This helps users understand whether they are effectively refining their search.Provide a way to clear the filters and see all results. For example, the Contoso app's search results page provides a set of filters above the results, with counts next to each filter.Indicate why a search result matches the query.For example, the Contoso app's search results page in the screen shot highlights the user's query ("item") in each result. This is called hit highlighting.Let users navigate back to the last-viewed page after they look at the details for a result.When they search, users often look at several results as they gather information. Looking at a specific result and then getting back to the search results page should be easy.A common way to accomplish this is to include a back button in the app UI as shown in the screen shot. This back button should be used to go to the page that the user was interacting with before they submitted their search.
- If your app participates in the Search contract, you should consider enabling searchPane.showOnKeyboardInput. This gives your users the ability to search your app by typing directly into the search box of the Search charm when they begin typing. This is the same kind of behavior users are familiar with from using the Start screen on Windows 8. Many people will use a keyboard to interact with Windows 8, and letting users search by typing makes efficient use of keyboard interaction. Of course, you should not enable type to search on every page of your app. Consider where type to search would be useful for your users and enable type to search only for those pages. Use the following guidelines to help you figure out how to add type to search to your app so that it creates a positive experience for your users. Enable type to search on your app's main page (or pages).You should enable type to search so that users can type directly into the search box from your app. Do this for your app's main page and any app page that displays, directly or indirectly, all of your app's searchable content. Your main page is the page that is displayed when users enter your app. In some cases an app may offer multiple main pages that offer different presentations for similar content. In this case type to search should be enabled on all of these pages.Enable type to search on your app's search results pages.After users get search results they often want to search again. You should enable typing directly into the search box from search results pages, so that keyboard users can perform another search quickly.Disable type to search on most other pages in your app.In most cases, you should disable typing directly into the search box on pages that are not your app's main page or a search results page.For example, here is a list of some types of pages where we recommend that you disable type to search:Pages with one or more input boxes. You should disable type to search on pages that have input boxes because if users begin typing while they are viewing such a page, their input should appear in the boxes on that page instead of in the Search charm's search box.Scoped pages that display only a subset of the content that can be searched by your app. If users search your app from a scoped page, it might be unclear whether they can search all app content, or only content within the scope of the page. It's hard to predict what users will want, and having multiple search scopes (content subsets) is more confusing than a single, large scope. We recommend that you disable search when a user is looking at a narrowed set of items, to avoid confusion.Pages where your app supports "find in page" functionality. Often pages that display a single article, image, or item should let users locate a query on the current page ("find in page"). You should disable type to search on these pages because searching through the Search charm will take users away from the current page. For user experience guidelines about using "find in page" in your app, see Guidelines and checklist for find-in-page.
- Be sure to handle a search activated event for an empty query.When users open the search pane (through the Search charm), they can choose an app to search with when they enter a query into the search box. In your activated event handler, when your app is activated for search, you should also check to see if your app was activated with an empty queryText string.If your app is activated with an empty queryText string and your app is already running or is suspended, return to the app's last-viewed page. If your app isn't running or suspended, take the user to a landing page appropriate for this search.Generally, your app's home page is an appropriate landing page when the queryText is an empty string, but you can also design an app page specifically for this purpose.For C#/C++/VB, see QueryText.For JavaScript, see queryText.Save the previous state of the app when the app is activated for search.The power of the Search contract enables users to invoke an application for search from anywhere in the system by using the Search charm. The application must be able to respond to a search activation event at any time. Applications should save their state and provide users with a way to get back to that previous state where appropriate.Example: In a mail application, the user might have a partially composed message. At a later time, if the user switches to the mail app to search in it, the mail application should save the message as a draft and provide users with a way to get back to it.If your app is snapped, navigate to your search results page while responding to search activation.If your app is snapped when the user searches in it, the search activated event fires and your app automatically unsnaps. Unsnapping causes a size changed (or resized) event to fire, and your app becomes the main app on screen.The search activated event and the unsnap event are fired in this order:Search activated eventIn response to this event, your app should display its search results page for the query.Size changed eventIn response to this event, check whether your app has unsnapped, and if it has, adjust your app to become the main app on screen. Make sure your response to this event does not take the user away from your app's search results page. If your app doesn’t load the search results page, the user might feel that the app is broken and is not searching properly.Save the search results page, and the filters and scope for the last query in case your app is activated to search for that query again.The Search charm lets users switch between multiple apps quickly to compare results for the same search query. The user might submit a search query to your app and set filters for your app's search results. The user might then switch to another app, search that app using the same query, and then come back to view your app's search results again.When this happens, your app is activated for search again. Your app's search results page should show the same filters that the user set the first time your app displayed results for this query. If the current query is the same as the last query, you should not get a new set of search results, but instead load your previous search results page, including the filters and scope that the user had applied, and the exact location where the user was focused.
- When possible, include links to online versions of local content.If an application supports downloading content that is also available to everyone on the web, it could share links to the online content rather than copies of the downloaded content. For example, suppose that a news site provides a rich reader application but also publishes the same articles on the website. If a user wants to share an article with a social networking site, the reader application can share links to the online version of the article that the user is currently viewing.If you do not provide a website that enables everyone to view content, your application must share a copy of the content. For example, suppose that a photo viewing application does not have a corresponding website. The photo viewer can share the photos with a target application that can upload those to its own website.Respect user selectionsYour app can support content in multiple formats. It's important that your app respect the selection the user makes. For example, don't include a link to a webpage if the user has only selected a portion of that page.Set properties and use them to supply useful informationWhen you package data for sharing, you have the option to supply a variety of properties that provide additional information about the content being shared. Take advantage of these properties to help the target apps improve the user experience. For example, providing a title and description that conveys what the user is sharing can help when the user is sharing content with more than one app. Adding a thumbnail when sharing an image or a link to a webpage can provide a visual reference to the user. For more information on what properties are available for you to use, check out our documentation on DataPackage.DataPackagePropertySet.Provide a message to the user when sharing cannot be completedIf your application supports sharing but a particular sharing operation cannot be completed for some reason, provide a message to be displayed in the share window that describes the steps that the user must take to correct the problem.Don't display a message that sharing is not supported by your application.Windows will display a standard message to the user if your application does not support the sharing contract.
- Don’t provide alternate ways to invoke sharingRely on the share charm and share window. Do not create a Share command on your app bar, or create a Share button in your application window or context menus.Preseve user selectionsYour app should preserve the user's selection even after the Share charm closes. This can help users if they want to modify their selection, or share the same content to multiple targets.Provide a string that indicates what the user is sharingYou should provide a string that indicates what the user is sharing. For example, if the user is sharing a webpage, include a string that has the URL of the page. If it's an image, include a description if possible. Support sharing of copied dataIf your app supports a way to copy data in the app, you should also provide a way to share that same data.
- Keep the look and feel the same between your target app and your primary app.Align your target app with the design for your primary app, including elements like fonts, colors, and controls. The target app should feel familiar to people who use your primary app frequently.Keep interactions simpleAvoid time-consuming or complex interactions in your target app. In most cases, actions like text formatting, tagging people in photos, or setup tasks like connecting to a datasource, are best handled outside of the Share charm.Keep navigation to a minimumWhen a user selects your app to share content, Windows 8 automatically provides a back button for navigating back to the app list. You shouldn't depend on this back button—a target app can't use this button for its navigation. Also, avoid adding your own back button, or making your users navigate back and forth between multiple pages in your target app. Instead, use inline controls, such as progressive disclosure controls, select controls, and inline error messages.Don't use light dismissThe Share UI already uses light dismiss. Including another light dismiss element in your target app can cause confusion with your users.Acknowledge user actionsWhen a user taps the Share charm or invokes the Share UI, let them know that the system is responding to their action—for example, through an inline message—before closing the share pane. This helps give the user confidence that their share started successfully.Put important buttons where they can be easily reachedPut share buttons where users can reach them easily. We recommend putting share buttons on the right side of the screen, so users can reach them with their right thumbs.Remove links that lead users away from the sharing experienceWhen a user is sharing content, you should take steps to ensure they remain in the sharing context. For example, if your app has links that lead to other areas of your app (such as to a home page), you should remove or hide them so the user doesn't leave the sharing experience accidentally.Previews should match the actual content whenever possibleIf your app includes a preview of what the user is sharing, that preview should match what will actually be shared as much as possible.Use QuickLinks wellQuickLinks are links to your app that are customized for a specific set of user actions. Take advantage of these QuickLinks if there are specific actions (such as sending an email to a specific person), or there is a place (such as a photo album), that might save the user time and encourage them to share content with your app in the future.
- Keep the look and feel the same between your target app and your primary app.Align your target app with the design for your primary app, including elements like fonts, colors, and controls. The target app should feel familiar to people who use your primary app frequently.Keep interactions simpleAvoid time-consuming or complex interactions in your target app. In most cases, actions like text formatting, tagging people in photos, or setup tasks like connecting to a datasource, are best handled outside of the Share charm.Keep navigation to a minimumWhen a user selects your app to share content, Windows 8 automatically provides a back button for navigating back to the app list. You shouldn't depend on this back button—a target app can't use this button for its navigation. Also, avoid adding your own back button, or making your users navigate back and forth between multiple pages in your target app. Instead, use inline controls, such as progressive disclosure controls, select controls, and inline error messages.Don't use light dismissThe Share UI already uses light dismiss. Including another light dismiss element in your target app can cause confusion with your users.Acknowledge user actionsWhen a user taps the Share charm or invokes the Share UI, let them know that the system is responding to their action—for example, through an inline message—before closing the share pane. This helps give the user confidence that their share started successfully.Put important buttons where they can be easily reachedPut share buttons where users can reach them easily. We recommend putting share buttons on the right side of the screen, so users can reach them with their right thumbs.Remove links that lead users away from the sharing experienceWhen a user is sharing content, you should take steps to ensure they remain in the sharing context. For example, if your app has links that lead to other areas of your app (such as to a home page), you should remove or hide them so the user doesn't leave the sharing experience accidentally.Previews should match the actual content whenever possibleIf your app includes a preview of what the user is sharing, that preview should match what will actually be shared as much as possible.Use QuickLinks wellQuickLinks are links to your app that are customized for a specific set of user actions. Take advantage of these QuickLinks if there are specific actions (such as sending an email to a specific person), or there is a place (such as a photo album), that might save the user time and encourage them to share content with your app in the future.