This is a guest post by Jedi Weller and his team at OpenForge. They have been pioneering new ways of designing digital solutions, integrating cross-disciplinary teams, and sharing common knowledge across technology companies in various verticals. Their work at OpenForge continues to lay the groundwork for clearer communication and enhanced transparency in the technology and startup communities.

Dev Scoping – The Final Frontier

In our industry, it’s often the case that software developers feel frustrated with the scoping process and the ‘need’ to put a ‘fixed’ number of hours on a complex feature. Developers everywhere try to estimate based on experience and past projects, but the number of variables in software development scoping can prove to be a perilous task.

This problem is exacerbated in team environments with Junior and Senior developers working together toward common solutions. This often results in Junior devs feeling ‘peer pressured’ (even unintentionally) into reducing their scopes to match other developers.

So, we built a way to help.

JuntoScope (“Together We Scope”) is a free, open-sourced, anonymous scoping tool for teams. We built it using Ionic V3, Firebase 4.12.1, a Serverless (FaaS) Architecture, and the Teamwork’s Projects API. The app is available on Google Play and the App Store.

So – let’s talk about our experience in building JuntoScope. No marketing, no bs, just straight up “here’s how it works.” After all, it’s a free tool – we don’t care if you use it or steal it, but at least buy us a beer the next time you see us 🙂

Designing The App

The JuntoScope design process was actually led by our development team, which was a fun change of pace. It was the dev team’s first time acting as the client, so we used a couple of our team’s processes to facilitate the communication between design & feature requirements.

1. We started by printing these iPhone printouts and then hand-drawing the flow.
2. We migrated these to Sketch, with the design team using Abstract for design source control. We used the Sketch Ionic UI Plugin to make design easy.
3. In order to keep language the same for designers and developers, we created a ‘legend’, that represents page transitions, routing, and data passthrough, and then started building!

We open-sourced the sketch file, which can be found here.

Folder Structure

We opted for a feature-oriented file structure to focus on the four distinct features in JuntoScope. We believe this will scale nicely as we build further support and features.

• App      
  • Generic app bootstrapping, auth guard, etc.
• Assets
  • This project is simple, so we just keep the @fonts/folder in assets. In larger projects, we keep shared file assets and an organized file directory.
• Environments
  • Stores our production vs. dev environment configuration
• Features
  • We opted for a feature-oriented file structure, with four main features
• Models
  • Define our data models across the app
• Shared
  • We always include pop-ups, modals, etc. in a “shared” folder in our projects
• Store
  • See NGRX
• Theme
  • Shared variables.scss

Commit Sanity

We can’t emphasize enough the importance of succinct, organized commits. Specifically, we used these tools:

Commitizen – it’s freaking amazing (but also frustrating when you first use it).
Tslint – Yes, absolutely necessary.
Prettier – Seriously, do you want to worry about line-wrapping?

An Intern’s Perspective – Serverless Architecture

We used this project as a great learning experience for one of our long-term interns, Claudio Del Valle, who’s been with us twice now during his term at Drexel. So, we felt it only appropriate he should get a chance to explain the architecture. Check out the code for more details.

We wanted to provide a seamless experience across all platforms, so we were looking for responsiveness and data persistence. In this case, using REST would create too much overhead and would require an overly complicated architecture. Therefore, we needed a simple way to establish a real-time connection between the moderator, participants, and our backend. I imagine some readers are already thinking WebSockets by now. We thought about it too, but we turned to Firebase instead.

As I alluded to above, WebSockets have been the popular choice for many developers who are looking for real-time, bi-directional communication between client and server. They provide excellent performance and security. Additionally, using a WebSocket-based implementation would be cheaper than using what’s sometimes called a ‘pull’ system. This is when the client-side has to ask the server for new information constantly. Instead, using WebSockets can be thought of as a ‘push’ system, where the server can emit values to the clients and vice versa.

Our project architecture could be described as serverless. This means that we use a service that manages the servers for us, namely, Firebase. It not only hosts our data, but our backend consists of an Express app hosted as Cloud Functions on Firebase. Now, had we decided to use WebSockets and wanted to remain serverless, we most likely would’ve had to use a different service to host our server where we would manage the sockets manually.
Here is where we decided to remain as lean as possible by leveraging the service we were already using. Furthermore, by using a popular Angular library for Firebase, angularfire2, we were able to get the result we wanted.”

Custom Styling

Having an organized CSS and a style guide is incredibly important when creating an app. We always try to identify reusable and similar components to avoid code duplication and design inconsistency later down the line.

How to organize the code is a matter of preference; Ionic recommends organizing by platform. For this project, we took that one step further and kept the order of variables consistent.

For instance, our <ion-searchbar> component overrides are declared first in all 3 of our platform (iOS, Android, and Windows) sections.

We’ve also separated the responsibilities of variables.scss (framework variables) from app.scss (custom component styles) – though both are still global.

Lessons Learned – A Note From Paulina (@paulpaultweets)

You will notice at the bottom of variables.scss we import and declare our custom font called “Avenir Next”. It’s a lot of code for not a lot of value; so my recommendation is to avoid custom fonts, unless there is a quantifiable business justification for doing so. In addition, web application fonts result in very heavy load times. Keep this in mind!

As we’re building an application, I often find pieces I want to refactor and shrink down as I go along. I’ve found it’s best to backlog these items as I’m working, so that I can focus on the task at hand but still make sure the refactoring is completed.

Bugs & Challenges

The overall development and design of our Ionic V3 App took approximately 383 hours to build; we used Teamwork Projects to track billing/hours logging. Even though the scope of the project was not large (2-3 months), we had a couple of major setbacks along the way.

• New Experience – Designing Error States: Since this was the first time our dev team led the design process, we missed some of our normal process that includes thinking through error states and transitions. Luckily, we were able to identify a couple holes we found in the flow through trial and error.
• Change in Teamwork Authentication API: We found out on the app store submission date that Teamwork updated their API to a more oAuth based approach. Maybe we should have subscribed to those monthly newsletters earlier 😀
• We had no marketing language: As previously mentioned, we never intended to market this tool – it was just something we built internally. So when all of a sudden we have questions relating to the privacy policy, TOS, or app store listing, everyone drew blanks and we had to scramble to get all these resources together.

Final Thoughts

Overall, the project was a lot of fun, and the front-end implementation, bolstered by Ionic framework v3, was incredibly straightforward to use. We were able to experiment with the Function as a Service architecture through Firebase, which was a lot of fun too.

Most importantly, this tool allows us to really speed up our internal scoping process and keep our software development scoping ACCURATE by using the team average. The team likes this process, so we’re going to keep using it.

We’d encourage anyone else using Teamwork Projects to try it out as well and let us know your thoughts. If enough people request, we have talked about adding support to tools like JIRA and Basecamp, but for now, we’re just supporting one. By the way, the team over at Teamwork.com loves what we’ve built and has agreed to give a 10% discount to the community. Just use discount code ‘JuntoScope’. Thanks for the love Teamwork <3.

This project went blazingly fast by utilizing the Ionic Framework. The entire application was rebuilt from our proof of concept using Ionic 3 in just a couple of weeks, and the performance is fantastic. We schedule 0 hours to work on performance optimizations, which is a blessing for anyone who knows how arduous performance optimization can be.

If you DO decide to use it, we’ll be sharing more information with the community about overall server load usage, costs associated with FaaS per user, and anything else valuable we can think of (except, of course, private data). The nice thing about having a real production product that’s open sourced is it gives us the opportunity to talk about trials, tribulations, and issues that come up in a production app, live as they are happening.

Stay cool, Ionic Community!
@jedihacks

JuntoScope is available on Google Play and the App Store.