7

How Does Your Team Handle New Features for an Existing Product in HTML Prototypes?

almost 3 years ago from , Designer at Mono

Those of you who work with HTML prototypes on big projects, I am curious to hear your thoughts about this:

  • An HTML prototype of v1 of the project lives on GitHub and a build lives on a URL.
  • Developers who work on the v1 features use this prototype (both GitHub and the URL) as a reference.
  • We add new features to the prototype in new branches.
  • Those new features might overwrite certain views that exist in v1 of the project.
  • We want those features to be available on a URL for discussion purposes, without affecting what you see on the v1 URL that is currently shipping, since developers might still be working on that stuff.

I have some ideas about how to handle this, but I am curious to know how you handle this situation?

7 comments

  • Peter Vogt, almost 3 years ago (edited almost 3 years ago )

    Gitlab has a cool new feature called Review Apps that we've talked about using to support a similar scenario. https://about.gitlab.com/2016/11/22/introducing-review-apps/

    tl;dr:

    Review Apps are ephemeral app environments that are created dynamically every time you push a new branch up to GitLab, and they're automatically deleted when the branch is deleted. This sounds nice and all, but what good is it? Well, rather than having a single dev environment for a project, or even separate dev apps for each developer, you get a new app for every topic branch, automatically. This let's you test and demo new features without having to ask in chat "hey, can I deploy to dev?" It's even better for the people on the periphery. Product managers can check out exactly what a merge request is going to look like without having to download and run a topic branch. QA and other users can take a look without having a development environment installed on their laptop at all.

    2 points
  • Tony Jones, almost 3 years ago (edited almost 3 years ago )

    I use GitHub pages as development environment for prototypes. Our production is located on our own server (any separate server will be fine). I use Bamboo but you can use Jenkins or any other deploy tool to automate pushes. We have one button push process for everything. If I want my local changes on GH pages I just click deploy to dev. If I want on our server, I click deploy to prod.

    0 points
  • Taylor PalmerTaylor Palmer, almost 3 years ago

    Hey Xavier,

    We've avoided this problem by having a hosted "master" prototype that a designer downloads when they need to make a new prototype. It's the most recent version of the prototype.

    Once the designer has downloaded the prototype, they can refactor and break the code as much as they want because they're working in isolation. Each of those branched prototypes is hosted in a separate folder than can all be reached at domain.com/folder/index.html.

    If one of the new prototype features gets approved and implemented, we'll move it over into the master prototype.

    This isn't the purest way to branch prototypes (obviously), but we're also dealing with designers that are less code savvy then others so they: 1. Don't have to learn git, and 2. Can't mess anything up for anyone else.

    0 points
    • Xavier BertelsXavier Bertels, almost 3 years ago

      Seems like a good solution but in our case it's okay to be a bit more advanced. We're all designers but pretty tech savvy at the same time. If we see a chance and benefit to automate something, we'll do so!

      1 point
  • Alex StillwellAlex Stillwell, almost 3 years ago

    I would suggest using a second server/subdomain.

    For instance, one could be design-v1.yourdomain.com and the other can be something like design.yourdomain.com. The V1 server will be consistent but you can update the non-V1 server by building the GitHub branches you're actively working on.

    0 points