Feydra Help

Feydra allows any MVC web application to host front-end development by creating virtual sandboxes for each front-end developer. A virtual sandbox is a virtualized environment in which front-end assets (css, js, cshtml, etc.) can be selectively replaced without disturbing the back-end functionality of the web application. This virtualization allows back-end developers to create stubs for front-end functionality without having the actual front-end assets available at development time. The front-end developers can hook-up the components as they become available without impacting back-end development.

Feydra also greatly improves front-end developers’ ability to maintain and update their portion of the web application. If there are issues with the front-end functionality of the site, a front-end developer can easily update the front-end assets in their virtual sandbox and test fixes against a working web application; all without the overhead of maintaining a full Sitecore development environment or MVC application.

Ultimately, Feydra is designed to allow front-end developers to use their preferred development environment; make their changes in a virtual sandbox and test by pushing their changes to a shared location (File share, FTP, etc.) using standard tools.

It solves two problems:

1. It allows Front End Developers to work independent of Back End Developers. That is, FEDs do not need to coordinate with BEDs every time they want to change front end code. They can work independently and check everything into source control to bring it all together. This also allows the front and back ends to work in parallel reducing the overall development timeline.
2. It allows FEDs to work using their chosen design tool. That is, by separating the design process from the underlying CMS, Feydra lets FEDs design in any tool that can output the final result in CSS/JS/CSHTML (HTML).

Normally FEDs create the front end assets and Sitecore developers chop them up into components. With Feydra, SC devs can create the components as generically styled placeholders that express the data without any styling (essentially as divs). FEDs can update those on their own schedule, breaking dependencies between FEDs and BEDs and allowing for them to work in parallel.

Feydra allows Back End Devs to stub in placeholders for the front end, so the back end can architect and build the actual components based on those the IA has already designed using wireframes (or really simple ones used on every implementation). FEDs can be more efficient because they are working closer to the components, leading to less iteration. FEDs can work on the stubbed components and see how it looks in real time, without waiting for a BED to go and integrate their changes.

Activating can be done by one or more Front-end developers simultaneously - each developer can activate their own sandboxed version of the website, while being on the same physical website (which is why Feydra is so cool!). You can even activate as a different Front-end developer to see the changes.

All changes are shared inside source control as usual. Feydra just plays part in the testing of these changes and has nothing to do with source control

The FED team can test after they have copied over the changes to the FeydraRoot\<User> folder, and then make the appropriate <User> active using the Feydra console (which is accessed through http://<qa_site_url>/Feydra).

By activating their user through the Feydra console, FEDs can then see changes get visualized in the environment where Feydra is installed.

The user list gets populated by going to Feydra's control panel and adding users. Adding a user adds a folder for the user under the FeydraRoot folder inside the website's webroot, and also copies over some predefined folders to the virtual sandboxed folder for the new Front-end developer user.

Back-end developers do regular code and item deployments as they normally do. The back-end code can be deployed normally in the common test environment (where Feydra is also installed). This will allow front-end developers to start working on their own components - by using a virtual sandbox there - without having to set up a local (Dev) Sitecore instance.

Of Course!   After Feydra is installed on the server and configured properly follow the steps below!

1.      Open the control panel in your browser “/Feydra”.

2.      Select: Activate as “USER” (your user).

3.      Open the file you want to edit (CSS, JS, CSHTML) in your favorite editor.

4.      Save the file to “/FeydraRoot/USER/…” on the server (be sure to match the path).

5.      Refresh the page in the browser and see your changes.

 *Note about #4 – saving the file on the server depends on your project configuration (Unc path, remote access, FTP, etc.).This step could be automated, depending on the editor you use.

Typically, the IA team would do wireframes, then design would get involved to do the layout and component designs. Then the front end would cut them up into CSS/JS/HTML, and then the back end would start building the Sitecore componentry, leading to iteration between FE/BE as the designs and components were dialed in.

Now back end can figure out the components, data and taxonomy from the wireframes and build unstyled versions (which are vastly easier to build) from the wireframes.  FEDs can then start encoding the designs using the unstyled components that BE built.

No, for two reasons.

1. There are typically two kinds of components to set up: simple ones that take 5 minutes, and complex ones that are unique to the project. So a reusable set only buys you an hour or so on the first type and is not applicable to the second type.
2. You lose the entire drag and drop page construction that frees your marketing team to pump out pages without back end help.  SXA pays for itself on that alone in about 2 months.

Feydra is good for classic Sitecore development where you are doing a full implementation – a “from scratch” implementation with lots of customization or complex design.

SXA is a great fit when there is not a ton of complexity or when there is a lot of content managed components (or both). Feydra is probably a better choice when either budget is constrained or if the componentry will be complicated.