HTML5 has been a big step forward, but it does not really deliver in terms of fluid interfaces, particularly for mobile. Older methods of DOM access and manipulation are flawed, and ripe with performance issues. Dealing with these issues is complex. Everyday development cycles should be abstracted from having to deal with limitations like these. Famo.us does this for us, and from what I’ve seen so far – it does it well.
Browsers have gotten really good. Our desktop machines are crazy powerful. Most of the time folks aren’t cognizant of any performance issues with the sites they browse on their desktop machines. All of this often masks the limitations of HTML/CSS/JS, or poor implementation by the developer. On mobile devices however, the cracks in HTML5 start to show. Although smartphones and tablets today are indeed amazingly powerful for their size, the mobile browsers they tote are a far cry from their desktop cousins. This is where it becomes quickly apparent that HTML5 is not as magical as we think it is – or have been told it is. When Zuckerberg – of Facebook – said “The biggest mistake we made as a company was betting too much on HTML5 as opposed to native” it was a huge blow to the perception of HTML5 in the mobile space. Recently there have been rumblings of a Front End framework that is solely focused on providing a toolset to use HTML5 in a performant way. This framework is Famo.us, and it wants badly for the web to win.
Famo.us is alot of things; a 3D layout tool, a physics engine, a native wrapper (yet to be seen), a MVC (yet to be seen), but more importantly it’s an attempt to solve the biggest rendering performance issues of HTML5. Stabs to crack this nut in the past have fallen short in my opinion. Sencha Touch is a very mature JS MVC with a rich UI kit, however it is beholden to a heavily nested DOM which will grind your app to a halt if you try to get too fancy. Ionic framework is a more modern attempt to create a UI kit for mobile, and leverage AngularJS as the app convention. Although the DOM is much lighter, it doesn’t address a fundamental issue of nested elements, reflows, repaints etc.
Famo.us recently entered a controlled beta – adding a few hundred accounts a day, and allowing access to early guides and documentation. I am excited to be attending HTML5 Dev Conf for hands on Famo.us training and hackathon, and to be a part of this beta release. What I have seen so far is very promising. There are a few things that Famo.us is doing that will give a speed boost to the DOM by addressing how we structure and think about modern web apps.
There is a great article on HTML5 Rocks – A resource for open web HTML5 developers about CSS3 and hardware acceleration. What is not mentioned in that article the the transform matrix3D – which allows a 16 digit matrix of values to describe a point in space in a 3D perspective along with rotation, skew, and scale. Famo.us wraps this property up and uses it as the main driver of it’s layout engine – flipping brilliant if you ask me. This allows them to run operations against multiple matrices of modifiers for super performant, complex transitions. Deeper under the hood Famo.us leverages the JS method “requestAnimationFrame” to know when to update the matrix – ensuring users perveice the UI at 60fps.
Nothing really groundbreaking here I would say. Caching reference dom objects is one of the first things listed in any best practices guide for DOM speed. Many frameworks have optimized themselves around reducing DOM touches. They all have their own special flavor on how they get that done, but the concept is straightforward. I like to think of JS and the DOM as being on opposite sides of a river. There is a bridge and, as with all bridges, there is a bridge troll. Everytime the bridge is crossed in order for JS to talk to the DOM, the troll blocks your path and charges a speed tax. Famo.us’s modifier / surface separation allows the developer to care less about accessing the surface, since the modifier is where all the slick transitioning is handled.
The performance problems that Famo.us is attempting to address, along with the rich catalog of physics, animations, and other features included make it a framework to definitely keep an eye on moving forward. Bootsoft is committed to the open web, and are looking to leverage any piece technology that helps us move that goal forward. When Famo.us is ready for prime time, we will happily find the right project to unleash it on.
The face of front-end development is in a constant state of flux. Web applications are becoming increasingly front-end driven, and the concept of a single page web-app powered entirely by REST-ful web services is the new norm. While libraries like jQuery have dominated the landscape for many years, they no longer provide all of the necessary tools for today’s client-side development world. The result is a major push from the front-end community for more robust tools and frameworks that make up for these deficiencies, one of the most popular of these is AngularJS. Where jQuery is a toolbelt, Angular is framing, plumbing, and electrical.
Angular addresses boilerplate bloat code with a more graceful document life-cycle, then allows you to access this functionality through additional HTML attributes/tags/class known as directives. All of the functionality you would have to add using Backbone is moved behind the scenes. The philosophy behind Angular is that web applications are living documents that should update in real time. Creating dynamic client-side applications should not be such a messy endeavor.
The big win with Angular is two-way data binding. In a traditional web app, when a page renders it takes data, merges it with a templating system and then displays that data to the user. At that point the rendered page is essentially static. Developers have to manually wire events for clicks, hovers, keystrokes etc, that update a data model or collection of models based on those events. The page then has to re-render the page using the template and updated data model.
Two way binding is a huge timesaver, and also helps the developer think more in terms of the state of the app – which leads to a more consistent experience for the user. Angular is massively robust and contains many other tools that allow for rapid development. Dependency injection, custom directives, services, factories, and host of other nuts and bolts place Angular squarely in contention for the go-to JS framework. I should also note that Angular is a product of our friends at Google, and so we may have a relatively high level of confidence in it’s progression and ongoing maintenance.
Agile is everywhere. In the 13 years since the publication of the Agile Manifesto, the term has slowly become a common part of the tech vernacular – and that’s a good thing. For years, the majority of us in the development community have pretended that if we just sat still long enough, thought hard enough, made swank models, had a lot of meetings to collect requirements, and incorporated feedback from peer reviews on our designs and specifications that we would create the best product possible. I have a lot of swank diagrams, data models, and technical specifications that I’m pretty proud of, but when the rubber meets the road, ‘stuff happens’ and there is always the regret that we did not have more time for development or find that super key thing that was missed.
Collectively speaking, we have always made up for those mishaps with a lot of coffee, all nighters, a few stressed out PMs and a lot of refactoring. Riding down the waterfall in the best constructed barrel has certainly served us well, but I have always felt like something was fundamentally wrong. Agile taught me that I was not crazy for thinking there was a better way, or that our efforts were misplaced.
Helping lead the way in the Agilification of Bootsoft has been one of the more rewarding professional experiences I have had. There is a greater sense of ownership across the board and quite frankly it just makes sense. Working with clients to shape a product from start to finish is very satisfying. When involved in these type of projects, most team members feel like they have a say in the direction of the product as it develops. They’re not just handed a massive tech spec and told “Go.” At the same time clients can see, touch, and feel the product as it goes through development, which obviously helps build our mutual understand and confidence along the way.
That’s not to say Agile is always the right choice. Tackling an Agile project requires a close-knit team of highly motivated individuals. It requires discipline; albeit a more creative kind of discipline, but discipline none the less. It requires more training. The Agile methodology has only recently hit universities and most of us have waterfalling ingrained in our DNA. Unraveling traditional methods and educating clients and colleagues is no small task.
You’ve also got to take the time upfront to reap the rewards. People are resistant to to long retrospectives, planning, and estimation sessions because most of us are simply so scared from a seemingly relentless line of unproductive meetings. We all have a tendency to fall back on old habits and comfortable ways of working. You need a few ah-ha moments to keep the shift in style and tactics in place. It is not as easy as enacting a new policy and insisting everyone follow. It requires coaching and determination. I guess this is why they invented the scrum master – to keep everyone honest about the process and priorities.
Despite this, I am a convert. There is a better way, and Agile is it. Agile will lead you to a better product faster. In other words – you can believe the hype.
Early last year, Bootsoft introduced the Bootsoft Learns Together program (BLT). The big goal being to continue to grow and learn new and interesting things. One cool thing about the program is that the topic is not limited in scope to what we do here at Bootsoft — or maybe it is, since we’ve been known to dabble in everything from music, to puzzling, to art, and of course software! Another cool benefit is that Bootsoft donates BLT hours for all employees, so you can actually do this while at work!
The development group decided that we would learn Scala. A small group of us signed up for a functional programming course via the popular learning site, Coursera and chugged on for several weeks. The class itself was comprised of lectures, quizzes, and homework. The lectures were about 5 to 15 minutes long per session, with an embedded quiz. Homework assignments were due weekly and got fairly involved, especially towards the end. All in all, it was a great learning experience. The group got together once a week to talk about the class and share ideas on the material itself, including applying our new-found knowledge to future project work.
Riding our Scala-high, we immediately got together to talk about our next learning adventure. That talk resulted in us deciding to attend and iOS class. The class we signed up for was an ongoing series offered by Stanford University. These were real full classroom lectures that were recorded and published. The format was therefore very different than what we were used to from the Scala class. In fact, most of us agreed that we were bored with the delivery of the material (mostly due to the length of each lecture). As a result, we decided to try using the class material as reference to aid in building some real iOS projects in-house. This effort resulted in three projects, two of which were dropped. The final of the three is still on-going and will be released to the public later this year.
We learned from the iOS class that it was next to impossible to keep up with Apple’s lightening pace of iOS version releases without sacrificing real project work and deadlines. We also learned that it was much easier to stick with the class to the end if the format was more suited to a heavy multi-tasking environment. That is, bite-sized chunks over long drawn-out sessions.
Generally, though we got something started and now it is once again in full effect, as a couple of team members have picked up Mongo DB for developers, another online course that is formatted very much like the Scala course and shows great promise for usage in future projects at Bootsoft.
On a regular basis, Bootsoft developers face complex and mind boggling software development challenges. The kind of problems that were solved in high school by the Mathletes because they were too bold and too dangerous for the classroom. Sometimes a single developer can find the solution right away. Sometimes it takes a whole team. Sometimes the team get stumped. Befuddled. Fatigued. When that happens, we bring in Mark. Mark is our clincher. Our relief pitcher. The Resolver.
What makes Mark such an ideal clincher? Experience, for one. Mark has been with Bootsoft for over a decade and has worked on multiple projects across multiple technology stacks and with multiple clients. Second, consistency. A project manager’s dream. I can even tell you what Mark is going to have for lunch tomorrow. Third, his cool and calm demeanor. It is exactly what is needed in an emergency situation and is the trait of a true leader.
In addition to Mark’s keen ability to hone directly in on the problem at hand, he is also a talented software architect and tech lead who is able to see the big picture.
Congrats Mark, you nailed it!
Bootsoft is always trying to find ways to contribute to the community, and one of our favorite ways is using our skills to give back! Over the weekend of November 1st-3rd, we had another GiveBack NY event (formerly named Create-a-thon). Since our last event in April 2013, we’ve partnered up with GiveBack DC, rebranded, and made another website for another well-deserving non-profit.
The group we worked with this time was Sports2Success. They use sports as a platform to empower today’s youth to help them pursue employment and become contributing members to the workforce. Through Sports Leadership Training and Apprenticeship programs, they build up kids with the confidence to excel in life, and through a career.
Working with Jamaal King, the Founder of Sports2Success, we were able to gather all the information and content for the website to get going. By creating wireframes prior to the event, it helps us plan a swift course of action for designing, coding and testing over the weekend. One of the challenges we faced, was the fact that there weren’t any photos of the group yet, so, Jamaal had an idea of creating a dynamic animation for the home page to help show what the organization is about. He sent us an idea for what it could be based on, and our designer Seung-Yun took it and ran with it! She was able to create the impressive animation that is on the home page using solely CSS and HTML. (You can view the site >>here<<)
The look-n-feel was created by myself, Kate B (the event coordinator for GBNY). I was inspired by S2S’s original logo, which was updated and simplified on the new site, and a theme of orange and dark grey/black used on their previous site. I wanted to add another accent color to the layout that wasn’t as bright as the orange color, and I felt that a pleasant teal-blue color complimented the orange and blended with the black and greys. I wanted the site to be engaging but simple, so a user could go to the site and quickly know where to go depending on what they wanted to do. I also wanted the site to have a fun and youthful look to it, seeing that it is a program for kids, but because the target audience is volunteers and supporters, I still wanted it to have a professional and organized feeling, as well.
Once I had the overall design ready to go, the developers were ready to jump in! We worked away all day on Saturday and got a ton of work done, to come in on Sunday to finish off the project and do some testing. For this project we used WordPress as a framework with Foundation and SASS. Everything went pretty smoothly, and we are so happy with the finished product!
Thank you to everyone who participated in this incredibly successful weekend, and can’t wait to begin planning our next event. If you or someone you know are involved with a non-profit in need of a website revamp – please apply at www.givebackny.org
It’s not every day when one of our longtime clients comes to us and says “We want you to build something cool.” Of course all of our projects are cool, but this was slightly different. Coldwell Banker wanted us to build a piece of software to wow their prospective franchisees. After some discussion about what this might look like, the video wall project was born.
Video Wall – Main Screen
The Video Wall is basically a giant interactive map of the United States displayed on a television screen. All over the map are tweets from real estate agents in different cities and states capable of being filtered by specific hashtags. Users control the map using their hands via the Microsoft Kinect, a motion sensor unit we attached to the television.
Coldwell Banker gave us a lot of flexibility on this project. We had an overarching goal for the project, but we knew some of the finer details would be discovered over time. This made it a perfect Agile project. Agile is a method that involves incremental development broken down into phases called sprints. Instead of all of the functionality being defined at the beginning of the project, functionality is discovered over time with input from the client. At the end of each sprint, a functioning piece of software is delivered to the client for feedback and the goals of the next sprint are laid out. In this way we were free to try a bunch of new things and find the perfect solution for our client.
My role in the project was development using the Kinect. The first challenge was selecting what technology to use. Microsoft provides a software development kit (SDK) for the Kinect using Microsoft Visual Studio and C#, which has several built in functions to recognize gestures and movements. There are also several third party SDKs, which I tried over the course of a month in addition to Microsoft’s Kinect SDK. In the end I decided on Microsoft’s.
The third party options are mostly low-level C++ implementations that largely come out of research projects and minor experimentation by various entities. Although some seem very useful (and certainly flexible), the revisiting of writing C++ code would be a big contributor towards avoiding these APIs. Additionally, the availability of support wildly varied by project and relied mostly on how active (in the project) and responsive the developers are. The issue of course is always time.
One of the biggest challenges was implementing gestures. Some gestures the Microsoft SDK provided functions for, such as dragging the map by closing your hand. More complicated functions like zooming in or zooming out I had to code from scratch.
To zoom in or out on the map, the user first has to hold both hands up in front of the screen. Then, the user has to close their hands and either pull their firsts apart to zoom in or push their fists together to zoom out. These functions were not provided in the SDK. That meant I had to write a lot of low level code to recognize these gestures. This turned out to be a little more tedious than I anticipated.
Overall it was a quite a fun project. The Kinect also has the capability for facial gesture recognition and voice recognition, so we only really scratched the surface of the full range of functionality. It was great to get to learn some new technology. Thanks CB!
Working with someone is a huge commitment. You spend hundreds of hours collaborating, debating, struggling, and eventually succeeding alongside your peers. Trust is an inherent part of any relationship, and getting into the virtual trenches with someone requires a great deal of it. My working relationship with Ian has spanned multiple companies and countless projects. There is no developer I would rather have at the keys than Ian Ainley. He is a superb programmer, but more importantly is dependable, and trustworthy. There is calmness to his swagger that helps to right the boat when things get rough, and I have never seen a task or impasse get the best of him.
Ian’s work is uniformly accurate and timely. On a project that was particularly complex – Ian built the front end for something called “Blue Wall”. This ‘wall’ integrated a live twitter stream using web sockets to display tweets on a full screen map. The user then interacted with the map using motion captured by an X-Box Connect. Ian hand rolled a custom event dispatch system in CoffeeScript to handle the incoming tweets and motion events into what is truly fun and exciting user experience.
These are only a couple of the projects Mr Ainley has been working on, and there is no question that he has Nailed It.
The last time I wrote about Responsive Design was about a year and a half ago, and there have been so many updates and advancements. I wanted to take this opportunity to talk about how I’ve been using responsive design lately and what I’ve learned by doing so.
In my role as a User Experience Designer at Bootsoft, I get the privilege of seeing new projects move from inception, to design, to development. A big part of designing a site or application, is planning out the architecture. After meeting with the client and hashing out the product’s needs and functions, I do some sketches and conceptual wireframes. Through the wireframes, I am able to annotate and map out on a more general level how things are going to interact. After going through some iterations with the conceptual wire frames, we begin making a clickable prototype. The clickable prototype can be very helpful for showing the client how their product is going to work. Without having to worry about any of the back-end, we are able to show them a prototype that looks, feels and functions like they expect a website or an application to work.
For these prototypes, I have been using the responsive front-end framework, Foundation (http://foundation.zurb.com). I am a big fan of this tool, because it is easy to implement, it has a bunch of great add-ons for prototyping that make mocking up a website quick and easy (like modals, image sliders, etc). It is also based on a grid, like the majority of responsive frameworks. The grid creates a layout that is controlled by percentages, so when changing the browser size, the content is flexible and logically rearranges itself.
One of the nice things about Foundation is that you can style it as much or as little as you like. Their core look and feel is actually very attractive – especially the buttons, forms and other added components. It’s clean and unobtrusive, which helps the client hone in on the core functionality of the user interface & experience instead of getting hung up on graphic elements.
We have used this framework for quite a few new projects, and so far it has been very successful both from my perspective and the clients. It is very intuitive and definitely makes my life easier when making clickable prototypes. What is nice about it is that when I need to make updates or changes, it’s incredibly easy and flexible to do so. As we move more into the Agile process, it is very important to work with technologies that are fluid and easy to work with, so for the wire framing and prototyping part of our project, Foundation has proved to be one of the best ways to keep with the rapid process.
I am really enjoying this method we’ve adopted for the discovery process, and I’m excited to keep moving forward with new and advancing technologies. It is so important to keep up-to-date with the direction of development and technology, and I am glad we’re are doing so, especially in this early part of a project. If you are trying to figure out a way to express specific functionality to a client, and flat wireframes just aren’t cutting it, I highly suggest using a rapid prototyping tool like Foundation!
To many, developers are seen as a commodity that only differs in cost. Projects are often given to the lowest bid. The thinking is, so what if the tech team working on my project is in India, China, or some other remote part of the world? In Bootsoft, we have seen first-hand how this can have dire consequences on projects and which is why all our projects are not only managed by a project manager in-house in New York but also led by a resident technical expert who is not only fluent in technology but is able to understand complex businesses processes and the interdependent relationship between business and technology.
David Bebawy is one of our brightest tech leads for several reasons. David has the technical skills to handle any task thrown at him no matter how complex or daunting it seems. Need a LAMP (Linux, Apache, Mysql, PHP), telephony, or e-mail expert? David is your man. David not only excels technically but has a keen talent for understanding business processes. While some expect a developer to simply complete the task at hand, David goes the extra mile to make sure that the task at hand does not negatively affect the entire project and often proposes better solutions. This is key in high profile and high traffic sites where one small mistake can have a snowball effect and take down an entire site or application. David is able to see the big picture even while focusing on leading the development team in ironing out the details.
For the last three years, David has focused on working on LeadRouter, an enterprise-grade real-estate lead management system used by hundreds of thousands of agents and processing millions of leads each year. David’s mission is to support this large-scale application and ensure both its short term stability, performance and long term success.
Gone are the days where clients can sit in a vacuum, come up with pages and pages of requirements, hand them over to developers, and expect a polished finished product. Developing and maintaining enterprise online applications is quite a complex endeavor that needs to be handled by an all-star technical team led by someone such as David.
Congratulations to David for this well-earned recognition and I am confident that David will continue nailing it in future and projects to come.