How to … create a slider

Screen space is precious on a mobile device. That’s why special navigation patterns have been developed to display relevant app content in the most efficient way. We recently showed you 7 commonly used mobile navigation patterns including typical use cases. You can quickly build those navigations with Pidoco, and we’ll take a closer look at one of them today: the slider.

The slider is a great way to depict progressive or closely related content on a minimum of screen estate by displaying successive parts of the content in the same section of the screen, often while keeping the rest of the screen static (much like in a typical module tab pattern). Based on natural gestures you can swipe to the left or right and see content that is only displayed when your slider is in a specific position. For instance, take a transportation app where you can use the slider to switch from one transportation option to the next (e.g. car, train, bus or airplane etc.). To avoid a fiddly navigation, not more than 7 options should be used.

The slider consists of the following parts: Usually a horizontal bar that acts as a visualization of the sliding process. Several elements (e.g. bubbles, round shapes, rectangles) on the bar represent the specific slider states, each of which is connected to specific content.

And here’s how it goes …


1. Setting up the project

For this post, I will use a transportation app with three transportation options as example. To build our slider, we will need several layers that will contain the content specific to each of the three slider positions. Everything around the slider will remain static, so we will use a page for all that content. So, let’s create a new project as well as one page and the three required layers in the beginning. (Hint: Don’t forget to give your layers unique names.)

We commence with the start page and add the static content. Here I added a status bar and a title bar as well as some text and an image. The slider will be positioned at the bottom of the page, so we will leave some space there and continue with the layers.

Adding the static content to the start page

Adding the static content to the start page


2. Creating the slider

2.1. Building the basic structure

Now let’s create our slider. First, we go to the layer panel, select the first layer from the list and start editing. The slider will go to the bottom of the app and will have one element for each option. Here I used three round shapes for each slider position, added some labels and a line to connect the three options.

Building the basic structure of the slider on the first layer

Building the basic structure of the slider on the first layer


2.2. Customizing the slider

Now we can customize the basic slider and add the specific content for every position that is only displayed when the user moves the slider. Here I added some information about travel distance and duration.

For a better visualization of the selected option the current slider position can be highlighted. That’s why I used a bigger round and green shape and an icon.

Adding a highlighting element to the basic structure of the slider

Adding highlighting element to the basic structure of the slider


2.3. Adding interactions

Finally, we can make the slider interactive. To do so, add an Action area to the inactive slider positions and right-click to open the context menu. Select the “Interactions” tab and add a new interaction. In the Interaction dialog that opens, select the pairing “When the user swipes”, select the desired direction (left or right), and set the reaction “change layer visibility” to only show the layer for the selected slider position and to hide the other layers.

Adding interactions to the slider to create the swipe effect

Adding interactions to the slider to create the swipe effect


2.4. Completing the slider

Now we just copy the entire slider with its interactions to the other previously created layers to paste it there. By default, the slider will conveniently be copied to the same position. Finally, we only have to adjust the reactions (which layer to show) within the Interaction dialog as well as the highlighting of the slider.


3. Simulation

Voilà! To test your slider, just open the Pidoco app on your mobile device (available via Google Play or the App Store) and start the simulation of your project by selecting it from the project list.


And if you need a little inspiration, here’s what my project looks like.


That’s it! You have successfully created your first slider! Do you need help? Then do not hesitate and drop us a line via or Facebook and Twitter.

Happy Prototyping!

7 popular mobile navigation patterns

One of the biggest challenges in designing an app for a mobile device is the limited screen space. But worry not! It’s possible to meet the users’ expectations and to create a neat looking UI at the same time – with the help of different navigation patterns. We have selected 7 commonly used mobile navigation patterns for you and listed them below, including typical use cases as well as little prototype examples (linked in the images).


Overflow menu

Problem: The user wants to have quick access to additional information and options within the app.

Solution: Overflow menu. With the overflow menu, you can easily stow away extra options and functions that are not used very often, but are still relevant to the context. Often they come along as hamburger menu, three horizontal lines or dots. For instance, such menus include options for refreshing the mail inbox or creating a new contact or group in a messenger or accessing settings.


Quicky access additional information via the overflow menu

Overflow menu: Quickly access additional information via the overflow menu



Problem: The user wants to choose smoothly between various options within one view of the app.

Solution: Slider. With the slider, the user can easily switch between various options just by swiping. While dragging the slider from side to side, s/he can benefit from transitions between different selections and quickly get an overview.

Choose between different display options using the slider

Slider: Choose between different display options using the slider


Swipe views

Problem: The user wants to navigate between content of the app, but doesn’t want to go back or use an extra navigation button.

Solution: Swipe views. Using the swipe view, the user can quickly and easily swipe through the content of an app. As already known from a photo gallery, this is a handy method to go back and forth and switch from one app or content “tab” to another.

Swipe between app content without extra buttons

Swipe between app content without extra buttons



Problem: The user wants to jump between different views of the app, but doesn’t want to leave the current site.

Solution: Sidebar. The sidebar contains the secondary view of the app and e.g. additional options like a navigation list or chat or user settings. It’s a neat collapsible panel that is hidden and only slides over the main view or moves it aside when accessed. This sidebar is often combined with an icon such as a hamburger menu or settings icon (gear wheel).

Jump between different app sections without leaving the current view

Sidebar: Jump between different app sections without leaving the current view


Vertical navigation

Problem: The user wants to navigate between different areas within the app, but there’s only very limited space to display further details.

Solution: Vertical navigation. Like in a list, the user can scroll that vertical navigation which includes all the necessary information in a very compact way such as account details, settings etc. Often this navigation pattern is combined with a sidebar.

Navigate between and scroll through app sections with only limited screen space

Vertical navigation: Navigate between and scroll through app sections with only limited screen space


Sticky navigation or tab bar

Problem: The user wants to access specific options or menus the whole time while using the app.

Solution: Navigation and/or tab bar. If the user scrolls the app, the navigation or tab bar will remain in place at the top or bottom or maybe also at the side. This is especially helpful when overall information or important buttons should be visible all the time, for instance, in an address book, where each alphabetical section stays at the top when scrolling, or in a photo gallery that keeps the headline sticky.

Access fixed app content the whole time

Sticky navigation: Access fixed app content the whole time


Content based navigation

Problem: The user wants to choose between different options.

Solution: Content based navigation. With a content based navigation, supported by neat page transitions, the user only has to successively swipe the screen to make one simple decision at a time. For instance, a swipe action to the left means “no”, one to the right means “yes”. The decisions can be checked later in a different view.

Choose between different app options

Content based navigation: Choose between different app options



Want to share newer, more fancy or different mobile navigation patterns? Let us know and drop us a line at


Happy prototyping!

How to … work with a grid system in Pidoco

A little while ago, we introduced our new grid feature. The grid feature was inspired by the wide use of grid systems in design and development and helps you

  • quickly build complex layouts within a prototype,
  • easily create multi-device layouts, and
  • set up a clean structure throughout the entire prototype.

Basically, the grid consists of customizable columns that contain all your site’s content and help you align elements easily. A “snap-to-grid” function makes aligning even easier.


1. The grid system in Pidoco

Working with the grid is simple: Just open a page of your project and click the “Show Grid” link above the canvas. The grid icon next to the link opens the dialog that lets you adjust your grid settings: You can set the number of columns, the gutter width between columns (to give the columns some padding), as well as the margins on either side of the grid. Finally, the grid width serves to define the total space available to your design and acts as an overall container that is centered relative to the device screen (much like the container concept in common grid frameworks). A grid preview right underneath the settings helps you choose the right values. Smart defaults will get you started right away.

Activating the grid in the Editing Panel

Activating the grid in the Page view

Since you may already be used to working with grid systems, here are some recommendations for settings corresponding to defaults in widely used grid systems you might want to use.


2. Working with the 960 Grid System

One of the most common grids is the 960gs. Optimized for “modern monitors” that “support at least 1024 × 768 pixel resolution”, this grid layout is still often used because its base number of 960 is highly flexible, being divisible by 2, 3, 4, 5, 6, 8, 10, 12, 15, 16, 20, 24, 30, 32, 40, 48, 60, 64, 80, 96, 120, 160, 192, 240, 320 and 480. The “container”, which holds the actual content of the website, is split into either 12 or 16 columns.

The 12 column grid (source: under CC Attribution-Share Alike 3.0 Unported)

The 12 column grid (Source: under CC Attribution-Share Alike 3.0 Unported)


2.1 Using 12 columns

You can recreate the 12-column layout of the 960 Grid System exactly by using the following grid settings in Pidoco:

  • Columns = 12,
  • Grid width = 960px
  • Margin = 10px
  • Gutter = 20px.

This is what the 12-column grid looks like on a 1024 x 768 pixel screen.

Using the 12 column grid on a website project

Using the 12 column grid on a website project


2.2 Using 16 columns

To work with the 16 column variant, you can use the following settings:

  • Columns = 16,
  • Grid width = 960px,
  • Margin = 10px,
  • Gutter = 20px.


3. Working with the Bootstrap Grid System

Another commonly used system is the Bootstrap grid system. This grid system takes into consideration that modern devices come in many forms and shapes ranging from very small screens (like on smarphones) to large widescreens (like many current laptops) and allows developers to easily plan for responsive scenarios with a “mobile first” approach. Depending on the target device size, there are five grid tiers with increasing container width (the container width describes what portion of the screen is actually reserved for the content and essentially corresponds to the grid width in Pidoco):

  1. extra small (XS): device width of less than 544px, no container width,
  2. small (S): device width between 544 and 768px, a container width of 576px,
  3. medium (M): device width between 768px and 992px, a container width of 720px,
  4. large (L): device width between 992px and 1200px, a container width of 940px,
  5. extra large (XL): device width of more than 1200px and a container width of 1140px.

The Bootstrap grid system assumes an additional margin of 15px on either side of the content, so the effective container width actually comes out to  be 30px wider than the specification lists, e.g. 1170px for the XL variant. If you work out the exact numbers for, say, a 12 column grid, you will find that this results in half-pixel dimensions (e.g. 97.5px in XL). Modern devices deal with this through their rendering engines, but since Pidoco only uses full pixels for projects, you need to approximate the default grid tiers. Here’s how…

To use the XL grid size (container width including margins of 1170px) in Pidoco projects, we recommend the following settings:

  • Columns = 12,
  • Grid width = 1164px (a little less than 1170px),
  • Margin = 15px,
  • Gutter = 30px.

This example shows a website project on a 1366 x 660 pixel screen. The result are 97px columns – 67px plus 15px margin on either side.

Using the Grid XL on a website project

Using the Bootstrap XL grid tier on a website project

You certainly will have noticed that is does not exactly fit the default column width of 97.5 px as prescribed by the Bootstrap specification. That’s why we approximated the settings with a column width of 97px, resulting in a grid width of 1164px and thus a deviation of 6px compared with the Bootstrap container width of 1170px. (Note: We recommend erring on the side of less space when designing, but if you would rather have 6px more, just set the grid width to 1176 px.)

And this is what it looks like:

Example prototype using the bootstrap XL grid

Voilà: An example using the bootstrap XL grid


That’s it! You have successfully applied a customized grid to your Pidoco project!

Do you need help? Then do not hesitate and drop us a line via or Facebook and Twitter.


Happy Prototyping!


7 Common Mistakes While User Testing

Users complete realistic tasks using your website or app, comment on their actions, moderators guide them, observers watch and listen, others take notes. That’s how a usability test is typically set up. Its purpose is to identify problems regarding the usability, find out how satisfied the participant is, and collect data for making informed design decisions. That’s in an ideal world… But even if you follow best practices like those found at, there’s still a lot that can go wrong. Here are seven common mistakes during a usability test you shouldn’t make.


#1 Testing the user

The most important point at the beginning: You are testing the usability of your website or app – not the user! The participants of your test should be aware of that. Why? You want honest and reliable feedback, and the best way to get this is to make your testers feel at ease – at least as much as possible. They should behave as naturally as possible. After all, you are trying to get insights into real-life situations. Usability tests by their very nature put participants in an artificial and often slightly uncomfortable situation. So the first step toward meaningful test results is to overcome this unnaturalness by reassuring your testers that they can do no wrong during the test. Otherwise, you risk that they will feel insecure or won’t be honest and speak out their real thoughts.

Test your product, not the user. (Source:

Our advice: cross out the term “user test” in your papers and in your mind. Everywhere. Maybe even start your introduction with “We’re not testing you, we’re testing us.” It’s a usability test! Plus: make your participants feel comfortable. If possible, visit them in their natural habitat instead of using a usability lab. All you really need is at least enough space for all your test participants (test user, observers, moderator) and recording setup. Or you could consider a remote test, allowing your test users to stay right at their desks, especially if your users are located somewhere else.


#2 Testing too much

Setting up a test is exciting, especially if you have lots of new features coming up or want to test different design versions. But don’t try to test everything at once or fitting every possible task into one session! Otherwise it’s likely that you will either tire out your participants or run out of time and don’t get the desired test outcome. Also, consider who you want to recruit for your test: Not everybody in your target audience may be able to afford to spend the time. The typical test session has a length of 60 to 90 minutes at most and contains 2 to 3 test scenarios. So you can’t test everything at the same time. You need to stay focussed!

Focus on roughly 3 test scenarios to avoid testing too much. (Source:

To avoid struggling during the test session, good preparation is needed: Create a list of all the things you want to learn from your test prioritizing the most important tasks and questions (see #3). Items with a lower priority can go to an extra list for later consideration if there’s still time left towards the end of your usability test. Prepare some extra minutes to have some time left rather than running out of time.

Another good way to avoid overwhelming test users is planning to run a longer usability test and break it up into several sessions focussing on different aspects.


#3 Asking the wrong questions

Many usability tests start out like this: “Take a look at this homepage and tell me what you think.” or “Take a moment to look around the site.” Don’t waste precious test time on artificial questions like these. You are trying to simulate real conditions in a usability test, but real people don’t come to your site to just browse around. Instead, you are giving away critical insights as you are allowing users to familiarize themselves with your site before the real test has even started. No, people who will use your website or app for real will do so with a specific objective in mind. So you need to make sure to test your design against those objectives. In particular, you should focus on the “red routes” – tasks that are critical for the users and/or the organization and thus should be as smooth as possible. This will also help you stay within the allotted session time (see #2).

Another type of question to avoid are leading questions (e.g. “That new button looks nice, right?” etc.). Instead of learning from the testers and hearing what they really think, you will hear what they think you wish to hear. Instead, ask open-ended questions (e.g. questions starting with W words – what, when, where).

Test your questions to find out if they perfectly fit the test. (Source:

Finally, be careful how you answer questions the participant might ask you. While you can’t (and shouldn’t) prevent your test users from asking questions, try to answer them with another question. Otherwise, you might be led to compromise the outcome of the test by giving away answers or introducing a bias (e.g. “Clicking here will guide you back. What did you expect to happen?” etc.). Don’t tell them the answer. Instead, ask them for their experience or let them articulate their first impression or expectation. For instance you might respond to a question with something like “What do you want to do?”, “What can you do here?”, “What do you expect to happen?” etc.

To minimize questions from participants in the first place, you should test your questions in advance (see #4).


#4 Failing to do a trial run

To avoid getting sidetracked and ensure comparability of results across test sessions, it is best practice to create a detailed test outline that includes all the important tasks and questions you want to ask, often even the introduction text to read out. A commong mistake, however, is to not test your test. Just like you are testing your website or app, you should do a trial run of your usability test. Even if you have prepared a detailed test guide and feel well-prepared, there are lots of things that can go wrong under real-world conditions. Just a few examples: The tasks you prepared may be unclear to participants, requiring spontaneous explanations that may lead to giving away too much information. Or tasks may simply take longer than expected, putting you and the testers under pressure. Or even worse yet, your equipment might not work the way you expected so you may end up leaving participants waiting or not being able to record things or run the test at all. Or you may have overlooked an inconsistency in the test outline that may trip you up. Better to catch that before the actual test!

Use a guideline and run a pilot test. (

That’s why you need to do a pilot test to determine how long the test will take and if your planned structure makes sense. Finally, once you have created your test guide and made sure it is well-structured and works, stick to it. Don’t digress from the scenarios and questions you prepared for the test session.



#5 Focusing on what they say

A common method in usability testing is “think-aloud”, i.e. asking the test participants to speak out what goes through their head as the interact with a system and try to solve the tasks given to them. While this type of commentary may give you valuable insight into the user’s state of mind, relying on words can be dangerous. Why? Because what participants say may subjectively be true, but objectively lead to wrong conclusions. First, studies have shown that users are poor at introspecting into their own motivations, so asking the user things like “Why did you do this?” may produce faulty answers. Second, we may get tempted to add questions like “How much would you pay for this product?”, which may work with a large sample, but not yield reliable guidance with the typical test pool of 5-8 participants. Finally, users may feel obliged to be nice to you when really they want to bang their head against the wall out of frustration with your site.

Pay attention to the actions, gestures and mimic of your test user. (Source:

To avoid this scenario, focus on actions rather than words. Grant participants enough time to express their thoughts and perform actions during the test session, even if this takes a little while, maybe even longer than you expect. Often the participants have a specific mimic or make a gesture. Pay attention to them. Note where participants hesitate, where they seem to be searching for options. Don’t ignore it. Especially, if you’ve already run multiple tests and maybe noticed some patterns, every experience matters! Just because people stop at the same point of a test doesn’t mean it happens for the same reason. Be objective and treat every tester equally. Remind your users to speak out loudly and try to gather as much information as possible, but don’t be misguided by what they say.


#6 Interrupting the usability test

Preparing a test guide is best practice, as we already saw, but it is not sufficient. A common mistake is to interrupt the flow of the usability test by inserting unrelated questions. One example is, to ask participants for ideas for alternative design solutions. Usability tests are supposed to help you uncover problems. To do so they focus on problem behavior, e.g. by giving the testers tasks to perform in order to achieve a specified goal (remember, usability is defined as the “extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use”). If they fail, this is critical information for you. But if you then ask them what type of design would have helped them succeed instead of continuing to evaluate why they failed, this will switch the entire discussion, interrupt the flow and likely limit your chance of getting to the actual root cause of the issue.

Avoid unrelated questions that may interrupt the flow. (Source:

Stick to your test guide and avoid interrupting the flow of the test session with questions your participants are actually unlikely to be qualified to answer – most users haven’t studied design and don’t know what options are even available. Instead, test different alternative solutions to begin with. This will help you identify design approaches that work and those that don’t.

Of course, you should also try to avoid other distractions that may interrupt the session, such as background noise, technical issues or unrelated questions, e.g. by setting aside some time at the end of the session to address questions by the participant or observers.


#7 No documentation

It’s always about saving time. So often people ignore documenting their findings during a test session, but also mentioning which methodology has been used. Why take notes, if you can have a meeting afterwards, especially if there are other observers in addition to the moderator? But in fact, it should be possible to easily and quickly recap the test session and results need to be visualized for those who didn’t participate in the usability test. Without proper notes you risk missing important results, significantly reducing the value of your test overall. For instance, if you want to figure out how long it takes the user to complete a task or whether she was able to complete the task at all and how many attempts were necessary to do so, you need good data. That’s why a permanent record of the findings is essential.

Document the findings to distill actionable recommendations. (Source:

To avoid ending a usability test without proper documentation, make sure you have a designated person for taking notes during the session. You can also incorporate space for notes right into your test guide. It might also help to print out screenshots of important parts of the test to keep track of the context of your observations. After each test, schedule some additional time to go through your notes, consolidate findings from the other observers and add any additional information you might have forgotten to capture during the test. Ultimately, you want to produce actionable recommendations for the next design iteration that are based on real user behavior.

Pidoco & AppCooker at UXcamp Europe

UXcamp Europe is one of the largest BarCamps for User Experience Professionals uniting more than 500 UX enthusiasts from all over the continent and beyond each year in Berlin, the heart of Europe. Last weekend it took place again for the 8th time in summery Berlin at Erwin Schrödinger-Zentrum (part of the Humboldt University). Organized by a superb team of volunteers, it featured a wide range of insightful discussions, workshops, presentations and demos from the participants in as much as 10 parallel tracks. As usual, the organizers managed to create lots of room and opportunities for exchange and networking outside the conference room, be it in the shade of the large umbrellas near the barbecue stand or in the adjacent café.

A beautiful summer day at the UXcamp Europe

A beautiful summer day at UXcamp Europe

On Saturday, we had the opportunity to hold a workshop titled “Bring your iPads® – Prototyping On The Go”.  Using AppCooker, a professional app for prototyping on the iPad®, as our example, we had a vivid discussion on the pros and cons of mobile prototyping and the many opportunities it offers in the app design process. We designed mockups for an iOS event app on the fly with the workshop participants and had fun coming up with ways to improve the process from paper to digital prototype. It was great to speak to many of you and receive such valuable feedback. Thanks to all who attended!

After two days of UXcamp, meeting so many creative minds and enjoying the camp’s atmosphere, all that’s left to say is once more: Thanks for the great organization! Thanks to all the campers! Thanks for a great UX weekend!

See you next year!

Pidoco acquires AppCooker

Today is a great day. We are excited that the iOS prototyping and mockup app AppCooker will join Pidoco and strengthen our offering. The acquisition was announced this weekend at the UXcamp Europe conference, one of the largest BarCamps for user experience professionals with 500+ active participants from around the world that has been taking place in Berlin since 2009.

AppCooker: Prototyping on the iPad®

AppCooker: Prototyping on the iPad®

AppCooker is a professional prototyping app for the iPad®, which enables software designers and developers to create mockups of future iOS and watchOS® apps directly on the iPad® for presentation and pre-development testing purposes. The app was developed by Hot Apps Factory, a mobile software company based on the French Riviera, which specializes in the preproduction process of making beautiful iPhone® and iPad® applications.

The takeover is part of our vision to allow all stakeholders of the app design process to participate in prototyping activities across devices. We believe that existing as well as new users will benefit significantly from the acquisition. AppCooker will remain available as a stand-alone app to users via the Apple App Store® and will also serve as a basis for new products.

How to … create a slideshow or carousel

Slideshows or carousels are a neat eye catcher on a site and great way to present different information on limited screen estate. Additionally, they allow users to gain a quick overview of your offering and switch between different topics. With Pidoco, you can easily simulate slideshows and carousels using the “Extended Interactions” feature. And here is how it goes …


1. Setting up the project

To build our slideshow we will use several copies of the same page that will only differ in the section representing the slides. Here’s my project which represents the website of a small art museum. Let’s start by building the page that will contain the slideshow. Here I added some headlines and a text block, but note that I left some space in between for the slideshow. This will be the “frame” for our slide show.

Adding the fixed content to the start page

Adding the fixed content to the start page


2. Creating the slideshow

Now, let’s add the slides to our project. To add the slides, we will make a few copies of our initial page – we need one page for each slide (since my slideshow will consist of three different images, I will make two copies, so there will be three pages in total). To do so, we click the “Duplicate” button in the context menu.

Cloning the start page to create the slideshow

Cloning the start page to create the slideshow


Now we can start editing the slide: Open the initial page and add an image for the slide, as well as any other content you want to show on the first slide. I used an image, some text and a headline. In addition, I added a “Start slideshow” button to the first slide. Note that this puts the user in control of the slideshow, rather than starting it automatically when the page loads.

Editing the first slide

Editing the first slide


Do the same with the other two pages to create slides 2 and 3. To ensure consistency, all slides should have the same size and look.


3. Adding interactions

Finally, let’s set up the interactive part. To make the slideshow move, we will add several interactions to the start button. To do so, select the button and open the “Interactions” tab of the context menu. To use more than one reaction, click on “Add reaction” in the right column of the Interaction dialog. To initiate several subsequent slide transitions with just one button click, we can use a delay with each page transition. I chose 5 seconds for both transitions.

Using interactions to change the visibility of the slides

Using interactions to change the visibility of the slides


Note: Since all page transitions are counted from the first button click, the first transition will have a delay of 5 seconds, the next 10, 15, 20, and so on.

Hint: You can also build a slideshow using layers instead of several pages, by putting each slide on an individual layer and using an interaction that will display and hide the slides in the right order. In this case, however, you need to remember to order the layers such that the next slide is always displayed “on top” – or hide the slides that are not active with every new slide that is displayed.


That’s it! You have successfully created a slideshow! Do you need help? Then do not hesitate and drop us a line via or Facebook and Twitter.


Happy Prototyping!

Aligning interests: New release features customizable grid, icon colors, better zoom

We’re celebrating the arrival of spring time with a new release. Here is what’s new…


#1 Customizable grid

The new grid feature supports layouting your screens. The snap-to-grid function makes for an easy and precise arrangement of assets on the canvas. What’s more, you can customize the grid to suit your layout: Simply adjust margins, gutters and number of columns in the grid settings. A grid preview helps you choose the right values while smart defaults help you get started.

Using the grid to individualize the alignment patterns on your screen

The customizable grid helps align elements on your canvas


#2 Icon colors/icon search

Following a frequent request, we have added a color option to all icon stencils. And there’s more: Individual icons can be found via the Quick Search feature. Just type what you’re looking for and the matching icons will be displayed in the stencil palette.

Screenshot of icon color picker

Icon colors can make prototypes more realistic


#3 Improved zoom 

Sometimes you have to zoom your screen to better view your canvas. We have improved the zoom feature to easily let you see the current zoom level and make it easier to return to normal view. Simply click the current zoom level to reset to 100%!

Resetting your zoomed page

We constantly strive to improve Pidoco, but without you that wouldn’t be possible at all. So we can’t thank our test users enough for their loyal support and feedback.

If you wish to join our monthly usability tests, just send us a quick email to and we’ll be happy to provide you with more information. Stay tuned for more!


Happy Prototyping!


PS: Not a Pidoco user, yet? Why not register for a free 31-day trial today?

Pidoco accepted into BERLIN INNOVATION platform



We are very proud to announce that Pidoco is now officially part of the new technology platform BERLIN INNOVATION which was initiated by the Technologiestiftung Berlin (Berlin Technology Foundation) and is funded by the state of Berlin, the Investitionsbank Berlin and the European Union. Showcasing creative, cutting-edge products, services as well as processes made in the German capital, the platform presents a distinguished collection of Berlin innovations with the goal to establish Berlin as a major innovation hub and provide information to businesses investors, state-owned companies and the general public. With a clear structure, the platform gives insights into innovation projects, supports networking and collaboration, and provides businesses with access to new solutions.

The acceptance of Pidoco into the platform highlights the innovative character of the software-as-a-service product as well as the business potential that rapid application prototyping offers to organizations that invest in modern design and development processes.

For more information have a look at

How to … create a sticky header on a scrollable page

A study by Smashing Magazine conducted in 2012 revealed that “sticky menus” are 22% easier to navigate than menus that scroll out of sight. The reason is simple: users find what they are looking for more quickly if they don’t have to scroll. What’s more, without knowing why, all participants of the study showed a preference for fixed navigation menus. So, in this post we will take a look at how to create a fixed header section on a scrollable page in Pidoco that can be used for navigation and other content. And here is how it goes …


1. Setting up the project

Simply speaking, a fixed header (aka: “sticky header”) is a section of a page that has a fixed position at the top of the screen and doesn’t disappear when scrolling the page. Probably the biggest advantage of a fixed header is that it allows the user to easily and quickly jump from the bottom of a page to the top without the need to scroll up the entire page. To build our fixed header we will use two pages, an element called “scroll frame”, and a little trick: We simply divide the page into a fixed header section and a scroll section and only let the content of the scroll section (defined by the scroll frame) scroll. The other page will just serve as a container for the scrollable content and be linked into the main page.

As an example, I have chosen the “New contact” screen of an imaginary address book app. The sticky header section of the screen contains a navigation bar that gives the user two main options: going back to the contact list or saving the new contact. The section below the header lets the user add contact details and is scrollable due to the many options including name, address, telephone number etc. Here’s a preview of what my finished address book will look like.

Preview of the sticky header project

Preview of the sticky header project


2. Creating the sticky header

We start off with creating the sticky content of our screen, i.e. the section containing the fixed header. To do so, create a new page (smartphone portrait format) and add all elements that should not scroll with the page. In my example, this includes a status bar as well as a navigation bar with a title and two navigation controls.

Adding content to a fixed header on a project page

Adding content to a page to create a fixed header


3. Building the scroll section

Now let’s create the part of the screen that that will scroll. To do so, add a scroll frame stencil to the page and resize it to cover the entire part of the screen that should scroll.

Adding a scroll frame to your page

Defining the scrollable section using a scroll frame stencil

Now open the context menu of the scroll frame and click the “Create a new page” option from the “Target” dropdown. This will do two things: Create a new page, which be the container for the scrollable content of the main page, and link the new page into the main page via the scroll frame.

Creating a new page to build a scrollable page

Linking a new page into the scroll frame element to build a scroll section


4. Adding scrollable content

Now, all that’s left is adding the scrollable content to the new page. To actually be scrollable, however, the new page must be longer than the main page. So, make sure to increase the length of the page.

In my example I added several text input elements and text elements as well as icons to create a complete contact details form, including even a profile picture.

Changing the length of the page

Changing the length of the page

Finally, we can preview the result by clicking on the “Simulate” button in the toolbar. Here is what my finished project looks like.


That’s it! You have successfully created a scrollable page with a sticky header! Do you need help with your project? Then do not hesitate and drop us a line via support@pidoco.comor Facebook and Twitter.

Happy Prototyping!