https://blogs.office.com/dev

Here is the RSS feed for the new Office Developer blog: https://blogs.office.com/feed/?filter-audience=dev

Please join us in this new location to keep reading all the latest news about SharePoint development.

Don’t worry, we won’t delete any of these MSDN blog posts – they’ll stay here so you can continue to refer to them for the information you need.

Here are all the places where you can join the Office Developer conversation:

^{Twitter @OfficeDev}

^{Facebook Office Developer}

^{Yammer Office 365 Technical Network}

^{MSDN forums}

^{Stackoverflow [MS-Office] [Office365] [OneNote]}

^{Office Developer Center}

While developing sandboxed solutions that contain only declarative markup and JavaScript -- which we call no-code sandboxed solutions (NCSS) -- is still viable, we have deprecated the use of custom managed code within the sandboxed solution. We have introduced the new SharePoint app model as a replacement to those scenarios that required the use of managed code. The app model decouples the SharePoint core product from the app runtime, and this enables much more flexibility and gives you the ability to run the code in the environment of your choice. We realize that our customers have made investments in coded sandboxed solutions and we will phase them out responsibly. Existing coded sandboxed solutions will continue to work in on-premises SharePoint farms for the foreseeable future. Given the dynamic nature of online services, we will determine support needs for coded sandboxed solutions in SharePoint Online based on customer demand. NCSSs continue to be supported. All future investments will go to making the new SharePoint app model richer and more powerful. Accordingly, we recommend that all new development should use the new app model whenever possible. In scenarios where you have to develop a farm solution or coded sandboxed solution, we recommend that you design it so that it can easily evolve toward a more loosely coupled development model.

For more information about the app model written especially for experienced SharePoint developers, see Reimagine SharePoint Development.

Call to action: We want to make the app model great. Help us by identifying scenarios, APIs and feature gaps that make farm solutions or coded sandboxed solutions necessary today. Provide your suggestions and ideas in our UserVoice site.

This blog post was written by Brian Jones, Group Program Manager, Office Developer Platform.

Have you ever been in a situation where you need to create a SharePoint 2013 development environment quickly? Are you still working on SharePoint Solutions or are you building apps for SharePoint and you need a machine with SharePoint 2013 and Visual Studio 2013 on it? Do you just want to try out SharePoint 2013 development?

If you answered ‘yes’ to one or all of the questions mentioned above, and you have an MSDN subscription, we have good news for you.

We have released an Azure developer image that comes with SharePoint 2013 and Visual Studio 2013 Ultimate RC pre-installed. The image also contains scripts to provision and configure SharePoint 2013 with or without an Active directory running on a different machine.

Be aware that, if you don’t have an Azure subscription, you can activate your Azure benefit that comes with your MSDN subscription. As part of your subscription, you have free Windows Azure credits - up to US$150 per month! You can use them to build SharePoint development & test environments on demand with virtual machines and more. See Windows Azure Benefit for MSDN Subscribers for more information. In addition we have optimized Windows Azure billing—meaning you only pay for the virtual machines as long as you are working on them. When you are finished working, just shut down the virtual machine and you will no longer be billed for it.

Let’s have a brief look at the image and how to provision it. There are two ways to provision a virtual machine of that image. You can either use the portal or use PowerShell.

Use the Windows Azure management portal:

To create a new virtual machine from the Azure Management Portal, go to https://manage.windowsazure.com and follow the steps below:

1. Sign in to the Windows Azure Portal
2. Choose the plus sign (+) at the bottom of the Portal page
3. Choose Compute>Virtual Machine>From Gallery
4. Scroll down the image list and choose Visual Studio 2013 Ultimate RC and choose the arrow on the lower right corner

Figure 1. Virtual Machine image selection dialog box

The virtual machine creation wizard guides you through the process. We recommend an X-Large VM Size for SharePoint development.

The virtual machine provisioning takes about 5-10 minutes. Once the machine has been provisioned you can use remote desktop to connect to the machine. The next step is to provision SharePoint 2013. As mentioned the image is pre-loaded with software and scripts. The configuration scripts and software can be accessed by choosing the “Configure Developer Desktop” shortcut icon on your desktop. The scripts folder contains two scripts relevant for SharePoint 2013 provisioning and configuration and allow you to provision SharePoint as Stand Alone or SharePoint with Active Directory (the script assumes that the Active Directory is hosted on another Virtual Machine).

Both scripts will configure a basic SharePoint environment, meaning they create a Central Administration site and a Web Application with a Root Site collection. The Figure 2 shows the provisioned virtual machine with SharePoint Central Administration and sign in screen to use Visual Studio for the first time.

Figure 2. Visual Studio sign in

Please see Visual Studio Ultimate 2013 RC Gallery image for MSDN subscribers for a detailed walkthrough of how to provision and configure a virtual machine for SharePoint development as well as documentation for the included PowerShell scripts.

Use Windows PowerShell:

As mentioned in the beginning we also released scripts that allow you to provision a SharePoint 2013 development environment using PowerShell. In addition, the scripts also allow you to provision a Windows Server 2012 virtual machine with an Active Directory and join SharePoint to that domain. This opens up the full scale of SharePoint development. Full documentation for the scripts can be found here: https://visualstudio2013galleryimage.azurewebsites.net/#_Toc359582720. All the scripts can be downloaded from here: https://download.microsoft.com/download/C/4/B/C4BB2A5D-1296-4DB8-A448-ABEB13B5974D/ConfigureDeveloperDesktopSampleScripts.zip

Once your development environment is set up you can even access your on-premises source control from Visual Studio on the virtual machine by using an Azure Point to Site connection. Be aware that when setting up an Azure point to site connection, you must first provision the virtual machine into a virtual network. For more information about Azure Point to site connections see https://msdn.microsoft.com/en-us/library/windowsazure/dn133792.aspx.

Enjoy!

Boris Scholl

Sr. Program Manager, Cloud Platform Tools

From a user’s perspective, to access your OneDrive for Business library, you simply click OneDrive in the Office 365 menu bar, as shown in Figure 1.

    
Figure 1. Office 365 menu bar

Or you can always navigate directly there using this URL pattern:
https://YourO365DomainHere-my.sharepoint.com/personal/
    YourUserName_ YourO365DomainHere_onmicrosoft_com/.

But that’s from the end-user perspective. How do you access OneDrive for Business as a developer? In this example, we will use REST.

Note: If your Office 365 site is set up to use a custom domain—for example, contoso.com—your MySite URL will be of the pattern, https://contoso-my.sharepoint.com/personal/YourUserName_ contoso_com/.

Start with the basics

1. Sign in to your Office 365 SharePoint site, and navigate to your OneDrive for Business library using one of the two methods mentioned above.
2. Click the Shared with Everyone folder and upload a document. For this example, the document name is myDocument.docx.
3. To use the REST API to view the information on the uploaded document, construct a URL with the following pattern:
   https://YourO365DomainHere-my.sharepoint.com/personal/
       YourUserName_YourO365DomainHere_onmicrosoft_com/_api/web/
       GetFileByServerRelativeUrl('/personal/YourUserName_YourO365DomainHere_onmicrosoft_com/
           Documents/Shared with Everyone/myDocument.docx')
4. Copy/paste it into your browser. The XML returned should look like this:
   Figure 2. Example of XML returned by the REST API
5. To download the document, append /$value to the URL. When prompted to save the file, name it myDocumentDownload.docx, and save it.

Work with documents and other files as “items”

1. For definitive read/write guidance, see Working with lists and list items with REST on MSDN.
2. To experiment, upload a couple of files to the root Documents folder in your OneDrive for Business library. Now you can test out a few REST read calls in your signed-in browser.
3. Using this URL pattern:
   https://YourO365DomainHere-my.sharepoint.com/personal/
       YourUserName_YourO365DomainHere_onmicrosoft_com/_api/web/
   Append lists/Documents/items/ to it. Here you will get all the items.
1. To get the metadata for a particular item, modify items/ to items(n)/ where (n) is the specific item number you want to view.
2. To see the metadata for the file, append file/ (for example, items(n)/file/)
3. To download the file, append $value (for example, items(n)/file/$value)
4. You can also use in place of the above pattern lists/GetByTitle('Documents')/…, and the API will return the same results.

Work with folders and files

1. Files are often nested in folders, and you may need to drill down into the folder structure; or you may want to represent the folder structure and files in a user interface (UI). Using the following REST calls, you can also work with folders and files in a more logical way than just the “items(n)” sequential location as the pattern shown above. This is where getting folders by relative URL and subsequently enumerating all the files within a folder is really handy.
   For definitive read/write guidance, see Working with folders and files with REST on MSDN.
2. Assume the OneDrive file structure shown in Figure 3, where you have both folders and documents at the same level.
   
   Figure 3. OneDrive file structure with folders and documents at the same level
3. To retrieve all the folders, you will use GetFolderByServerRelativeUrl with the following URL pattern:
   https://YourO365DomainHere-my.sharepoint.com/personal/
       YourUserName_YourO365DomainHere_onmicrosoft_com/_api/web/
   To this URL, append GetFolderByServerRelativeUrl('/personal/YourUserName_YourO365DomainHere_onmicrosoft_com/Documents')/folders/.
   All the folders will be returned. You can then subsequently use the ServerRelativeURL property for each folder to continue to “walk down” each folder until you reach its end node.
   Figure 4. ServerRelativeUrl property of a folder
4. Likewise, if you want to return metadata about all the files in a folder, simply replace folders/ with files/, and all the files will be enumerated.
   
   Figure 5. ServerRelativeUrl property of a file
   
   Then, if you want to retrieve the file, use the GetFileByServerRelativeUrl URL pattern, described in the first section above, with /$value appended to the URL.

The above URL patterns show how to construct the REST calls for use in the browser for simplicity. However, you can readily implement these URL patterns in your code.

For example, if you are developing an app for SharePoint, the app can call into a user’s MySite site collection and access their OneDrive for Business documents using REST or CSOM.

The REST call to get to the file would be:
https://YourO365DomainHere-my.sharepoint.com/personal/
    YourUserName_YourO365DomainHere_onmicrosoft_com/_api/web/
    GetFileByServerRelativeUrl('/personal/YourUserName_YourO365DomainHere_onmicrosoft_com/
        Documents/Shared%20with%20Everyone/myDocument.docx')/$value

To programmatically get the OneDrive for Business URL for the signed-in user, you can make a call to the user Profile service:
https://YourO365DomainHere-my.sharepoint.com/_api/
    SP.UserProfiles.PeopleManager/GetMyProperties/personalURL/

Remember, your app for SharePoint needs to request the right set of permissions in the app manifest to access OneDrive for Business content—for example, AllSites.Read—and if using the User Profile service: Social.Read. When you request a token from Access Control Service (ACS), make sure you have the right audience. In order to call OneDrive for Business, you need a token whose target audience is https://YourO365DomainHere-my.sharepoint.com/. Also remember to encode all the query parameters in the URL.

This post does not detail these calls for CSOM, but the CSOM equivalents are available: see the CSOM, JSOM, and REST API Index. Other valuable resources are the articles on how to complete basic operations using CSOM and JSOM, and getting started with SharePoint 2013 REST.

Lastly, for sample code, download the Apps for SharePoint sample pack, which provides examples across C#, REST, and JavaScript. It contains useful samples, including:

• SharePoint 2013: Build REST queries and use REST to traverse a site
• SharePoint 2013: Perform basic data operations on files and folders using REST
• SharePoint 2013: Perform operations on SharePoint Document Library from PHP site.

Enjoy!

Yina Arenas, Program Manager, APPS PM

Donovan Follette, Sr. Technical Evangelist, Developer & Platform Evangelism

Xiaoying Guo

Program Manager, Office Developer Tools

Several questions came up during the launch webcast. We are planning a series of blog posts that should get everybody on the same page. Stay tuned!

Register for the webcast now

The Reimagine SharePoint Development site (https://reimaginespdev.com) officially launches on May 20. We created it specifically for current SharePoint developers who are interested in understanding more about apps, and who want to learn about the proven practices of architecting and developing apps and migrating SharePoint solutions to apps.

Our goal with this site is to help you understand when it’s best to develop an app, and when it’s not; what the proven practices are for creating apps for SharePoint; and when an existing SharePoint solution is a candidate for migration to an app, as well as how to do it. We plan to include MSDN articles and white papers, video content, blog posts from some of our MVPs about developing apps, migrating solutions to apps, and more.

As a SharePoint developer, you should make https://www.reimaginespdev.com your first stop when planning and developing your next app or migrating your existing SharePoint solution.

We want to know what you think! Please leave us comments and share your thoughts and ideas.

Related resources:

• Apps for Office and SharePoint Dev Center
• Sign up for an Office 365 Developer Site

Keenan Newton is a senior product marketing manager on the SharePoint team at Microsoft.

In the last few years, the use of mobile devices to surf the web has increased significantly. According to some researchers, by 2015, more mobile devices than desktop computers will be used to access the web. Mobile devices come in different sizes and capabilities. And since the desktop experience just isn’t good for mobile users, what are the options for improving the experience of mobile users on your website?

Improving the user experience across devices

Optimizing the user experience of a website across different devices is a complex process. Not only do you have to take into account the screen resolution of each device, but you also need to consider its capabilities (such as touch or pointer-based) and device size (1024x768 might be clearly readable for everyone on a 20-inch monitor but might result in a very bad experience on a 5-inch screen).

When you are planning improvements to the user experience of your website on mobile devices, there is no silver bullet approach. You have to research who your users are, which devices they use, and what they are trying to achieve on your website. You also have to have clear goals for what purpose your website serves and how it should guide your visitors in the process of becoming your customers.

You have several options for improving the user experience of a public-facing website. Which one you choose depends on the different factors that apply to your scenario.

Mobile websites

In the past, when the web technology wasn’t as sophisticated as it is nowadays, it was a common practice to provide mobile users with a separate mobile website to optimize their experience. Being hosted on a separated URL, such as https://m.contoso.com, the mobile site would have a user experience optimized for mobile devices. In some scenarios, organizations would even go a step further and optimize the copy on the mobile website. When a user navigated to the website using a mobile device, the main website would detect the use of a mobile device and automatically redirect the visitor to the mobile version.

It’s not that hard to imagine that building and maintaining two different sites is not only costly but also time consuming. Every update has to be done separately. Even then, with the diversity of today’s mobile devices, the questions remain whether a single mobile website would suffice and whether you wouldn’t need more websites to reach the whole spectrum of your customers.

Being able to reuse the content across the main and mobile websites simplifies the content management process. But the need to separately maintain the functionality of both websites makes it hard to justify this approach in most scenarios.

Mobile apps

One of the recent developments of the mobile market is the increased popularity of companion apps. By using the native capabilities of specific devices, you can build rich mobile apps to support different use cases. There is no better user experience on a mobile device than the native one offered by the device itself. For more information, see Build mobile apps for SharePoint 2013.

But is it realistic to build separate apps for all the different scenarios and for all the different mobile devices used to navigate the website? Although mobile apps are of great value for supporting specific use cases, there is still the need to access the information on the website from a mobile device in a user-friendly way.

Responsive web design

Instead of building separate mobile sites for mobile devices, what if we could have one website that automatically adapts itself to the particular device?

Responsive web design is a concept based on the ability to separate the design from the content on a website. Using the CSS media queries capability implemented in all modern browsers, and based on the screen dimensions of the specific device, you can load different style sheets to ensure that the website is presented in a user-friendly manner. And because CSS has its limitations, you can use JavaScript to further optimize the interface and interaction of a website on mobile devices. For more information, see Implementing your responsive designs on SharePoint 2013.

From the search engine optimization (SEO) perspective, responsive web design is the recommended way to optimize public-facing websites for mobile devices. After all, since the same HTML is sent to every device, it’s sufficient for an Internet search engine to index the content once, and it can be sure that the search results will apply the search query on every device.

Implementing responsive web design on a public-facing website is relatively easy assuming you start planning for it from the beginning. The great advantage of responsive web design above other approaches is that you maintain your website once to support a variety of audiences, and the different experiences are future-proof as they depend on the devices’ dimensions rather than their identity.

The following figures show how the sample Contoso Electronics website is displayed on different devices using responsive web design. Figure 1 shows the screen shot taken on a desktop device.

Figure 1. The Contoso Electronics website displayed on a desktop device

Figure 2 shows how the Contoso Electronics website looks like on different mobile devices.

Figure 2. The Contoso Electronics website displayed on mobile devices

SharePoint 2013 device channels

One of the new capabilities of SharePoint 2013 is device channels. You can use device channels to optimize how a website is displayed on different devices. By defining different channels and associating different devices with them, you can use different master pages to optimize how the website is presented to the user. For more information, see How to: Create device channels in SharePoint 2013. Figure 5 shows a sample configuration of device channels for a public-facing website built with SharePoint 2013.

Figure 3. Device channels configured for a public-facing website built on SharePoint 2013

Whereas responsive web design uses a device’s screen size to determine the presentation layer, device channels in SharePoint 2013 use the identity of the browser on the particular device to decide which presentation style to use. Depending on how many different devices your site visitors use, managing the different devices and experiences can become complex. By using device channels, you get more flexibility in controlling the markup of your website for the different devices. Another benefit of using device channels is that you can serve different content to different devices, whereas the same content is served when using responsive web design. With device channels, you can apply additional optimizations to your website, such as resizing images and videos server-side using the renditions capability, which further improves the performance and user experience of your website. For more information, see How to: Manage image renditions in SharePoint 2013.

With all the different options at our disposal, which one should we use to get the best results?

Improving the user experience of a public-facing website in SharePoint 2013

First and foremost, it’s important to note that SharePoint 2013 supports all the methods mentioned above for improving user experience on mobile devices. Whether you’re looking at building a separate website for mobile users, supporting certain use cases with a mobile app, implementing responsive web design, or using device channels, it can all be implemented in your website on top of SharePoint 2013.

Not only does SharePoint 2013 not stand in your way, but it also supports you in implementing some of those improvements. For example, using the cross-site publishing capability, you can easily publish the centrally managed content on both the main and the mobile websites. With the Search REST API, you can have your content published in your mobile app, and if you’re looking at optimizing the presentation of your website across different devices, SharePoint 2013 offers plenty of features to help you.

With all these techniques at your disposal, it is up to you to decide which method, or combination of methods, is the best choice for what you’re trying to achieve. While you might be interested in supporting a particular complex process with a dedicated mobile app, it might still be of added value to ensure that everyone, regardless of their device, can access all the information on your website.

In most scenarios, it’s easy to choose whether or not the particular optimization technique offers added value. A slightly more difficult choice, partly due to the similarity of both methods, is whether you should use responsive web design or device channels to optimize the presentation of your website for mobile devices.

Responsive web design and device channels comparison

Responsive web design and the SharePoint 2013 device channels capability are similar in how they let you optimize a single website to be displayed in a user-friendly way on different devices. Despite this similarity, there are a few important differences between both approaches. Table 1 presents a comparison of the different properties of both approaches.

Applying user experience

First of all, there is a difference in how both approaches determine which user experience should be applied for the particular user. Responsive web design uses the size of the screen to determine how the content should be laid out in the browser’s window. Device channels, on the other hand, use the identity of the browser to load the suitable channel.

While responsive web design can cause different experiences to be loaded depending on the size of the browser window, device channels will always load the same experience for the same device regardless of the browser window size. Using device channels can have great advantages, for example, from the troubleshooting point of view where the user and the helpdesk employee would see the same interface despite the possible differences in their screen resolutions or browser window sizes.

Page markup

Another difference between device channels and responsive web design is how the page contents are served. Responsive web design changes only the presentation layer of the website. Although you can hide some pieces of the page in the browser using CSS, they are still present in the website’s code and therefore loaded. When using device channels, you can use different master pages to ensure that only the relevant markup is served to users. Additionally, you can use the device channel panels to further control the content elements loaded on specific pages.

Although device channels allow for better control of the rendered HTML and therefore optimized performance of the website, more effort is required to ensure that Internet search engines will properly deal with all the different versions of the website presented to different devices. You can achieve this by using the Vary-By User Agent response header, but it has to be done manually.

Future-proofness

Responsive web design uses the size of the browser window to distinguish between the different experiences. This is a robust approach, and the chances are low that a new device will appear on the market that has a poor user experience despite the configured breakpoints. One reason for that might be related to some specific capabilities of such devices, but again, chances of this are very rare.

SharePoint 2013 device channels are based on the identity of the browser used to open the website. There are two challenges with this approach. First of all, in some situations it might be impossible to distinguish between the same browser installed on the same operating system but on two devices with distinct capabilities. Second, if a new device appears on the market, you would have to verify that this device is assigned to the right device channel on your website.

Choosing the right approach for optimizing the user experience

Although responsive web design and device channels are very similar, their capabilities differ and they have different impact when used for optimizing a website for mobile devices. Due to their similarities and their own strength, choosing between the two approaches is often difficult. Why not combine both approaches to get the best of what they offer?

Combining responsive web design and device channels

An interesting scenario worth considering is to combine responsive web design and SharePoint 2013 device channels to benefit from the strengths of both approaches.

When combining responsive web design and device channels, you could use responsive web design to create the baseline cross-device experience. Depending on your design for the different breakpoints, using responsive web design could be good for the 80%, or maybe even 90%, of the optimizations. The remainder—whether they’re caused by how the web design changes between the breakpoints or by the capabilities of the different devices that should be supported—could be covered by device channels and device channel panels.

By using responsive web design to build the baseline for the cross-browser experience, we benefit from its future-proofness and robustness. For the specific exceptions, we can benefit from the granular control that SharePoint device channels offer us.

About the author

Waldek Mastykarz is a Microsoft SharePoint Server MVP and works as a SharePoint consultant at Mavention. Waldek shares his enthusiasm about the SharePoint platform through his blog, articles published in online and off-line magazines and on MSDN SharePoint Forums. He is also a speaker at community events such as the SharePoint conference in London, SharePoint Connections Amsterdam, and SharePoint Saturday. In addition to his job at Mavention, Waldek is a Virtual Technology Solutions Sales Professional for Microsoft Netherlands. In this role he helps answer customer questions around SharePoint Web Content Management (WCM).

Blog: https://blog.mastykarz.nl
Twitter: https://twitter.com/waldekm
Mavention: https://www.mavention.com

Web designers are crucial for a successful SharePoint implementation. We all know that. With this in mind, I wanted to write an article for our SharePoint web designers out there. Not being an authority on the subject, I decided to ask someone who has been working in web design for some time. By asking my contacts, I got the email address of an expert in SharePoint branding and UX customization. Eric Overfield was the name on the contact card. I set up a conference call, and very soon we were chatting and discussing UX, branding, artists, engineers, and SharePoint.

The conversation quickly turned to devices and how to make SharePoint work as well as possible in this new and changing set of displays. Eric’s answer was: responsive web design. Responsive web design allows us to look at a site like a fluid grid. The fluid, dynamic grid adapts itself to fit the information in display resolutions as different as those in a phone, a tablet, and a full desktop monitor. Keep in mind that the mix of display resolutions doubles if you consider landscape and portrait orientations available in all these devices.

The author of the original post about responsive web design, Ethan Marcotte, provided a reference site to demo the concepts explained in his post. In this demo, you can observe how the elements in the page rearrange themselves to fit the current resolution as you resize your browser window. The demo left me wondering how a SharePoint website would react to different resolutions by using the fluid grid characteristic of responsive frameworks. Fortunately, Eric, along with some other people, developed Responsive SharePoint. Responsive SharePoint is a CodePlex project that you can use to try responsive frameworks on your SharePoint website.

I followed the provided instructions to install the resources by using Design Manager on an out-of-the-box publishing site. In no time, I was looking at how the site dynamically reacted to different resolutions as I resized my browser window. I decided to test the project by using the following display resolutions:

• 1200x1900 (desktop, portrait orientation)
• 768x1366 (tablet, portrait orientation)
• 480x800 (smartphone, portrait orientation)

The results were amazing. Within 10 minutes, I had a SharePoint website that automatically adapts to display resolutions commonly used in devices. The following figure compares the website in commonly used display resolutions:

Figure 1. Comparison of resolutions of the SharePoint website using a responsive framework

How is this achieved?

In this post, I can only explain that Responsive SharePoint uses media queries to match the width of the display in the device and then applies a set of styles to present the content in the available space. For this to work, you need a browser that supports media queries. The latest version of the major browsers support such functionality. The following code example shows how to declare media queries:

@media (min-width: 769px) and (max-width: 979px) {
    /*
        Styles for display width 
        between 769 and 979 pixels
    */
}

@media (max-width: 768px) {
    /*
        Styles for display width 
        equal to 768 pixels and thinner
    */
}

@media (min-width: 1200px) {
    /*
        Styles for display width 
        equal to 1200 pixels and wider
    */
}

Of course there is much more to it. You can learn more by browsing the Responsive SharePoint CodePlex project.

The new design and branding features in SharePoint 2013 make it easy to create and edit your web design, including responsive designs. You can even use the tools you are familiar with by mapping a network drive to the SharePoint 2013 Master Page Gallery. In my case, I used Microsoft Expression Web 4 to browse and edit the master pages and CSS files.

I am excited about the new design and branding features and how we can use them in responsive web designs. For more information, see What's new with SharePoint 2013 site development.

- Ricardo

Eric Overfield is the co-founder of PixelMill. PixelMill is a company that offers products and services for branding SharePoint starting with SharePoint 2007, and they have been in the web design business since 1998. Eric is very passionate about the community for whom he developed the CodePlex project Responsive SharePoint. He is also a speaker at SharePoint events, such as SharePoint Saturdays, and is in the process of writing a book about responsive design and SharePoint 2013. You can read more about Eric’s work at PixelMill’s blog and follow him on Twitter @ericoverfield.

The following options are available for you to create forms in SharePoint 2013:

• InfoPath
• Access
• Excel
• Visual Studio

For more information, visit the original blog post, Options to Create Forms in SharePoint 2013.