The Herff Jones Cap and Gown Sales Order Site was built using the foundational architectural and design concepts built in the Scholastic E-Commerce project.

Adam’s role on the project was to create an architecture founded on the principals defined previously, but suited specifically for the business needs around the Cap and Gown site. The web application was built using AngularJS, Java Spring Web MVC, Hibernate, Adobe CQ, and MS SSIS.

Herff Jones engaged with Roundarch in 2011 to help design and develop a new e-commerce experience for their scholastic product line. This effort included a massive integration of back end ERP systems into the site, as well as defining an architecture to support portals for each sales rep to customize products, pricing, and content specific to the schools and territories they represent.

Adam was the Technical Director of the technology program on this account. He oversaw several teams responsible for front end implementation, middle tier business logic, a customized enterprise CMS, integration to existing ERP systems, and the build of a custom 3D engine to visual class rings.

The Scholastic E-Commerce Site was built using Bootstrap, Less (and many other HTML/JS/CSS libraries), Java Spring Web MVC, Hibernate, Adobe CQ, a custom 3D engine built in Adobe Flash, and MS SSIS.

Recommendation based on this work:

“Adam is a strategic thinker and brought a wealth of experience and practical knowledge to the project. He always had a positive attitude to solving problems, shared best practices, and could always be reached for counsel.” October 1, 2012

– Sean Bradley, eCommerce Product Manager at Herff Jones (client) | LinkedIn

Related: New Herff Jones High School Site Launched

In 2011, Herff Jones engage with Roundarch to help them build “Stitch” – a social media platform that enables students to tell the story of their high school life. Stitch is a multi-channel, multi-tentant application that runs in desktop browsers, tablets and mobile devices. In Stitch users can share their photos in an engaging UI, read and publish “Storylines” about their school, and interact with the system and users to gain achievements (similar to Four Square).

Adam served as an architect and the technical director for this project. He defined the foundational architecture for the Flex Browser Application and worked with lead Flex developers to define the system architecture for the mobile and tablet efforts. The team also integrated several features with the organization’s enterprise CMS.

Stitch was built using: Adobe Flex, Blaze DS, AngularJS, Phone Gap, Adobe CQ, and Java.

Related:

• Herff Jones Stitch – Android Apps on Google Play 
• Herff Jones Stitch for iPhone, iPod touch, and iPad in the iTunes App Store 
• Herff Jones Goes Digital to Invigorate Yearbook Sales | 2012-05-19 | Indianapolis Business Journal | IBJ.com

Related:

• Pearson Eduction – Sneak peek of the new aimsweb
• Project Showcase: Pearson Education aimsweb

Related:

• Pearson Education – aimsweb Overview Video
• Project Showcase: Pearson Education aimsweb

Bloomberg Sports today formally launched its third season of “Front Office”; the latest, most comprehensive and easy to use fantasy baseball analytic tools on the market.  The updated offerings are part of the continued enhancement and customer support that has helped grow “Front Office” into the top paid fantasy baseball tool available in the marketplace.

The updated suite of tools in “Front Office 2012” for the regular season will include opportunities for users to obtain instant updates via text and email on players on their roster through the new ALERTS! feature, and an additional feature designed to support leagues that are specific to the American and National League. Fans will also be able to obtain a free customized analysis of their fantasy team, showing how they compare to other teams on each scored stat, as well as receiving customized recommendations to improve their team. The product will retain all previously added features, including the ability to sync with the major hosting sites from Yahoo!, ESPN.com, and CBSSports.com as well as others, in order to easily tailor all recommendations to all fantasy team and player specifications.

“The latest additions to ‘Front Office’ were a direct result of the feedback we have received from our subscribers, and we are very excited to add these pieces to what is already the most comprehensive and robust product available in the marketplace,” said Bill Squadron, head of Bloomberg Sports. “Our tools are uniquely customized for each fantasy player’s actual roster and settings, providing the best projections and recommendations each day, from the draft through the entire season.”

The launch of the new tools will give fans ample time to review and make the best possible choices for their fantasy drafts, most of which will take place in March. In addition to the ability to sync with almost any league provider, “Front Office” offers a customized B-Rank that provides up-to-date lists for roster changes, free agent pickups and other decisions, as well as a customized dashboard which gives players all critical information about their team or teams in one easy to follow location.

All of Bloomberg’s fantasy tools are now available in PC, MAC or for most mobile devices, giving fans the ability to access the tools from wherever they are.  Bloomberg’s Fantasy Draft product was the leading seller among paid sports apps in the iTunes store for most of the 2011 season, further proof that the Bloomberg sports analytic tools are quickly becoming the fantasy tool of choice amongst both avid and casual players.

Strategic partners for Front Office 2012 include:  Yahoo Sports, CBSSports.com, USA Today, and SiriusXM as well as the Society for American Baseball Research (SABR).

Source: Bloomberg Sports Unveils Latest Additions To “Front Office 2012” Fantasy Baseball Tools | Going 9 Baseball.

… Could have been the title of this post 3 months ago. Given the recent layoffs and announcements in the past few weeks, it may seem short sighted to be overly excited faced with this news today. This was, however, a part of the announcements recently by Adobe regarding Flex. They are committed to contributing Flex (and several complimentary projects) to the Apache Software Foundation (ASF). I personally witnessed the commitment and plan for this at their San Francisco office. Many leaders of the Flex community gathered at Adobe SF by request of group product managers Deepa Subramaniam and Andrew Shorten this week. We heard from senior management on their new strategic vision for Adobe around digital marketing and digital media. We heard apologies for the accelerated and miscommunicated nature of the messaging of the past few weeks. And, we, most importantly, heard about the future of Flex as it may likely live in the ASF.

There has been a lot of focus lately on the poor messaging to the community around the announcements of late. I don’t disagree about how destructive and misguided this messaging was, but I do think it’s important to see it as the past and move on. Many in the community may criticize this idea. It would be easy to say this is one of many moves towards under valuing the community. Again, I wouldn’t totally disagree, but I do think this particular moment in history is different than in the past. Here’s a bit of an explanation…

The ASF model for development is much different than how a product is developed by a corporate software vendor. On an Apache project there are no project managers, product managers, senior vice presidents, presidents, CEOs, CTOs, development managers, senior engineers, or any other title of a role that you can think of; other than “commitor”. A commitor has the right to commit code to and vote on a project. You can read a lot more about the ASF process on their site. So, what’s the big deal? Why is this different than a time in the past that Adobe (or any company) did wrong by it’s community, said “we’re sorry”, and kept moving right along? – This time they’re actually handing over the reigns of the project to us; to the community.

Adobe will not have contributors on the Apache Flex project. Neither will Spoon, Roundarch or any other corporation or group. This is (technically) true because contributors are individuals. So, there will be some individuals who are contributors on Apache Flex that will also be Adobe employees, but they will not have any higher status or privilege than any other contributors on the project. This is by design. The design of the ASF. The process of Adobe contributing Flex to Apache is in the form of a proposal. That proposal states the intention of all initial commitors to create an Apache Flex project, among other details. Up until Apache Flex is realized as a full project there will be a phase of incubation. During this time Apache will work with the proposal submitters to help arrive at a proposal that fits the Apache model. This is to ensure the best possible arrangement for a successful Apache Flex. That’s why this moment is different than similar times in the past. By this model, Adobe gives up the sole control and direction of Flex and enters into a partnership with the community to drive the future of the framework, with the guidance of Apache. Without that partnership Apache will not accept this contribution. So, for those claiming Adobe is “giving Flex to Apache to die” or “dumping off Flex with Apache”, this is simply not true. It also shows a severe lack of understanding and respect for what the ASF does and has done.

We have not heard this before. This is a new approach with a high potential for excellent collaboration of all the individuals and entities that depend on Flex for critical business needs. These individuals and enterprises need a path to a future that enables their teams and businesses to deliver the high quality solutions they (and their customers) are accustomed to. For many enterprises developing highly complex applications with millions of lines of code, large development teams, and high expectations for success, Flex was and still is an extremely valid technology, for others it is a requirement. There are enterprises that are so vested in using Flex to build (or maintain) a platform for their businesses that a short term migration is simply not possible. This is not an understatement. Individuals from enterprises like what I’m describing were present and vocal at this recent Flex Summit.

So, what else did we hear as it’s relevant to Flex?

A paraphrased quotation, as I can’t remember the exact wording:

Adobe will not continue to develop Flex as a “stand alone” business.

It was also stated that Adobe does not currently have plans to develop any product targeted at enterprise scale user interface development. That’s not to say they aren’t developing tools for HTML5 development, just not a platform like Flex based on HTML5. They are committed to their runtimes for what seems like a minimum of 3-5 years. All of the current runtimes (less Flash Player for mobile browsers): Flash Player for desktop browsers, AIR for mobile (iOS, Android), and AIR for desktop (Windows, Mac OS).  However, it does seem clear that this runtime development will be focused in line with their new strategy of digital marketing and digital media. For Flash that means game development and video. There are certainly concerns around this regarding Flex. Game development is very different from enterprise class development. They have also stated that they will commit to backwards compatibility to meet all the dependencies that exist today in Flex 4.6.

My thoughts on the future of Apache Flex…

Apache is the the future for enterprise class Flex. For those highly skeptical and critical of Adobe, my message to you is this: The move to Apache is a big one and categorically different from anything we’ve seen in the past. Is Apache perfect? I doubt it. What it’s not is proprietary or corporate. It also answers in no way to a group of public share holders. It is not driven by senior management who are making business decisions to please those public share holders. It has no “layoffs”. It is not driven by the sales of an IDE. Further more, it has no goals of making profit – at all.  It was founded and is governed by folks that really understand open source development. It is one of the most respected software foundations in the world. What Apache Flex can be is a powerful force for the community to drive the future development of Flex and deliver in a way that holds true with the most important needs of the community – governed and guided by the Apache model for open source development.

I also believe that development is just one factor in the future success of Flex. Now that Adobe is stepping back from Flex there will be gaps in the future in the areas of: education, community (user groups, conferences, etc), quality assurance, support, tooling and potentially others. The Spoon Project may likely provide an appropriate group to support in these areas. There are already of mass of talented folks rallied around problems similar to these gaps in Spoon.

So, down to brass tacks:

What’s the reality of HTML5 as it relates to Flex at this moment in time?

HTML5 and open standards for the web will play a dominant role in the future of technology. What I believe is that this future is farther off and a bit more uncertain than many that make this statement. Let’s consider some recent figures by IDC. IDC predicts that 90% of smartphones and tablets will have HTML5-ready browsers by 2013. This means that 90% of consumers will be able to access your HTML5 application on their smartphone or tablet by end of 2013 (still 12 months away). However, the Gartner prediction of 81% smartphone penetration/adoption for 2012 was off by 50%. That stat is actually 44%. Even looking at the past month, smart phone purchases are only at 56%, well below that 81% prediction. The staggering number is 2015. 90% browser adoption of HTML5 is estimated for 2015. The Flash Player has historically had 90-99% adoption in desktop browsers. Additionally, there is no complete HTML5 specification. Notice: “Draft”.

In that respect an even more staggering number is 0. 0 is, technically, the current browsers that support an open standards based implementation of HTML5. Without a complete open standard it’s impossible to have compliance around that standard.

As Google, Microsoft, Apple, now Adobe and others seem to have consensus around the support for HTML5 in the future, none of these companies seem to do a great job at messaging when, exactly, this future is. Along with that I think many analysts are also doing a poor job of analyzing and messaging the capabilities of current web technologies. Part of that problem is the term HTML5 is now being used for anything related to HTML. Current support for HTML, JavaScript and CSS is a lot better than it was years ago, but comparatively (both to what HTML5 will be and what Flex and the like are now) it has many drawbacks. There is still a considerable amount of browser fragmentation to deal with, there are considerable challenges with styling for some experiences, there is a severe limit to the amount of performance of any browser’s JavaScript “runtime”, and there is still a lacking of support for mature approaches to software engineering when it comes to JavaScript. That doesn’t mean I hate JavaScript or think it isn’t a great tool for solving a lot of problems. It is my opinion on the comparison of the available choices for developing software on the web today – not the how that may or may not look in the future.

In the future that is next week and next year, Flex still has a place.. and that future is considerably more relevant than speculation on what is 3 years away… but back to the topic at hand: Apache doesn’t hedge on those futures. It supports a thriving community interested in building software. This is another huge reason that I see so much potential for Apache Flex. So, you won’t be hearing me making blanket statements like HTML5 is the future and you shouldn’t be building Flex apps. Or, Flex will be around for decades and HTML5 is completely overrated. Anyone who makes makes these kinds of huge generalizations is in one (or all) of these categories:

• A person who is trying to sell you something
• A company man (or woman)
• A technology zealot

If you’re an engineer or part of management driving the technological future of your organization, it’s probably not a good idea to listen to these kinds of people as your only source of information (or maybe at all). The sales person is driven by profits. The company man is driven by a career towing the company line. The technology zealot holds to their particular technology views without necessarily analyzing the reality of the tech landscape. These are all risky people to put your faith in. The technologist that can analyze trade offs, discuss options, strategize to meet business goals effectively; that is a person who I trust. That is a person who I want on my team, working with my customers, and solving critical technology problems with me.

More to come on Apache Flex as it develops…

Google+ comments.

The Good.

Flex came to us at a time where there was a shift in the way we were using technology to build software for the web. AJAX was just a baby, even though many (including myself) had been doing AJAX like HTML development on the web, long before the term was coined. AJAX and HTML were a decent solution for many problems, but browser fragmentation was worse than ever, and the languages of HTML, CSS, and JavaScript were supported by browsers and tools in an arcane way. It didn’t add up to tools that made sense from a software engineering perspective. So, a lot of us turned to ActionScript. A language that was part of a platform better suited for engineering with almost none of the fragmentation problems that plagued HTML/CSS/JS. These fragmentation issues were, of course, solved by a runtime called the Flash Player.

When I first came into Flash I didn’t have a high opinion of it. I thought it was that timeline tool that designers used to make fancy ads that annoyed me. When I really dug into the language and the platform though, I saw potential. So, at the time just before Flex, like many others in the community, I was building Flex-like apps based on purely ActionScript and the Flash Player. As a young developer who had worked in more classical desktop user interface frameworks like Swing, Visual Basic, etc, ActionScript and the Flash Player gave amazing freedom from the limitations of the way browsers were constructed to deliver markup content via HTML. Markup is not a particularly desirable framework for engineering user interfaces – Flash was better.

Then came Flex. Macromedia saw a trend in the market: building applications on the web. They also saw that a lot of folks were using their runtime to do this. Possibly in a way Macromedia had never intended. Flex came as a solution to this problem. The main benefits of Flex in it’s prime:

• A standard user interface component set
• Remoting (the ability to interface with web services via transferring typed objects)
• A better skinning and styling workflow (than HTML/CSS at the time)
• Efficient vector graphics for data visualization (charts, graphs, etc)

These add up to an excellent offerring for organizations developing custom, business critical software to run their enterprises. Previously we had seen tools like Visual Basic and Java’s Swing and SWT frameworks occupy this space. Among others, a main downfall with these options was the requirement of IT professionals to support pushing out new builds of desktop applications across enterprises. Flex came as enterprise IT organizations grew tired solving this problem. At the same time the web was maturing to a point where these kinds of applications could actually be served from a browser. It allowed a single web deployment of an application that could be updated and serve many users to solve the business critical problems so crucial to the success of the operations.

This is what I loved about Flex, and still love about it. It was a tool that could be used to solve these problems for enterprises in a manner that was so much more effective and engaging than what I had previously seen in tech. It also opened the door to engage with user experience practitioners in a way like we hadn’t really seen before. When I started working with colleagues in user experience roles it changed the way I thought about software. We weren’t building something to fulfill a boring requirements document, we were engaging users to create an experience that was different than what they were used to getting from software. The goal wasn’t just to make a better widget, it was to redefine what a widget was. We’re still doing that today and it’s still exciting.

Flex is still one of the greatest UI toolkits I’ve used to build rich UIs. I am proud to have been part of community that shared this opinion and pushed the technology so much of the last few years. I have met so many brilliant engineers, user experience practitioners, and visual designers; all folks who embraced and defined what we know now as rich internet applications. I’ve learned a lot from all of you, and it’s been a great ride. To those of you at Adobe that contributed to the progress of the product; thank you. No product is perfect and your contributions to the field of user interface engineering are commendable.

The Bad.

Over the past few years it has been clear that the product development of Flex has shifted from an user interface engineering tool as pioneered by Macromedia to a tool more inline with Adobe’s offerings for designers. From a user interface engineering perspective, this was bad. There are clear examples of platforms, both present and past, that are designed for software engineers to solve complex problems. Tools for; testing (unit, integration, functional), profiling, continuos integration builds, code coverage, etc have been largely left behind in Adobe’s product development concerning Flex. I say this is bad, but I also understand that from a company who’s made most of their stake on PDF, Fonts, and Photoshop sales, it’s understandable. From a business perspective I’m sure Adobe was interested in having repeatable success with Flex as they had with Photoshop and their other creative tools. The problem is, Flex is not Photoshop and the theory that it could be has been clearly disproven.

Obviously, these are my opinions on choices made over the last several years as they apply to Flex as an user interface engineering tool. It’s also my opinion, that Adobe hasn’t really been set on the path to make Flex the best tool for this as they seemed to be up until around 2008-2009. That’s not to say Flex isn’t still a great tool for these problems, it’s just that it hasn’t made the progress it could have in terms of an engineering tool. This “bad” really adds up to lost potential to be the de facto tool for enterprises building web based applications. What’s really disappointing is that, before last week, Flex still had the opportunity to be this tool, with little competition. I personally know folks who have created proofs of concept around patching the Flex compiler to compile a Flex application to run in a JavaScript environment – and it works. Not to say this is a trivial effort, but it is something that can be accomplished. So, instead of Adobe evolving their own platform and tools around the trending towards HTML5 they’ve, more or less, decided to start over.

Starting over is actually not that bad of an idea, but the side effect of dropping commitment to the Flex platform is estranging a development community that has been passionately committed to the platform over the years. These developers are reasonably disappointed and angry to have been left out in the cold. I think it will extremely difficult to earn back that commitment in the future.

The Future.

So, Flex Developers, what’s next? Flex filled a need. A need we all were looking for and many helped shape, but it was a reaction to what the industry needed and how technology was trending at the time. It was not a proactive stab to solve a problem that was known. We all worked through this together to get to a place where we had something pretty great to solve the problems in our industries. So, the point is, we did that, and we’ll continue to do it again. The industry is trending again in another direction, and it will trend again and again and likely never settle. This is another thing I love about technology – it is constantly in a state of reformation.

Does that mean Flex is dead? Not necessarily. To quote Jesse Warden from a thread we had on Google+, “Sun fubarred Java, and it’s still straight pimpin’”. The community now has the opportunity to redefine Flex once again. Maybe a plan of compiling Flex to JavaScript isn’t far fetched for the community. Anything is possible. At the same time, this moment provides a good opportunity to sit back and look at the land scape in technology. A proper engineering mindset should arrive at decisions pragmatically, not emotionally. We have a new era in front of us that continues to show the importance of user experience but also clearly points to the importance of apps.

Forrester coined this new wave as the “App Internet”. We’ve seen the revolution of desktop applications converging on the web. In this next wave we will see mobile as a defining factor in the internet technology of tomorrow.

What we’ve all learned by using Flex is greater than Flex itself. We’ve learned and evolved the way we solve problems in technology more efficiently and serve our users more effectively. Adobe cannot layoff these skills and we can use them to continue to evolve software and the way we build it.

I am fortunate to be surrounded with technologists, user experience practitioners, visual designers, and strategists at Roundarch who combined represent expertise in almost all things relevant to modern software development. It’s a lucky spot to be in and I’m confident in our proficiency to adapt both reactively and proactively to trends like this in the industry.

So, learn JavaScript / HTML5, contribute to Spoon.as, or write the next new amazing UI framework. Just don’t stop writing great software because of the change in direction of one tech company.

Adam was a front end architect on this project, working with the Java architect and the entire team to define a foundational architecture to support the efficiency of the many developers contributing to the project. The core of aimsweb’s technology was built using Adobe Flex and Java Spring.

Related:

• Pearson Education – aimsweb Overview Video
  
• Pearson Education – Sneak peek of the new aimsweb

The New York Jets command center core was built using Adobe AIR, Adobe Flex and Java Spring.

Related:

• Jets Owner Leaves No Stone Unturned
  
• Jets Want to Know What You’re Buying
• New Meadowlands Stadium Features Revolutionary Fan-Friendly Technology
• New NFL Technology Brings Fans Closer to the Action