We took on a monumental challenge this past week. We had a new client using Adobe Muse. Nothing special about that beside the fact they learned that Adobe Muse is being retired in a few years and they wanted to be ahead of the curve and were already concerned the product wasn't working the way they needed it to. The largest concern with the Adobe Muse site was they stated the website loaded slow with the fastest page being around fifteen seconds to load. So we took a look and these are our findings with their site.
The first thing we did was make a backup of the site onto one of our test servers. The site took a long time to transfer over our fiber optic connection. The site size ended up being 21.4 Gig, yes GIG!!!!, or 23,040,184,320 bytes in size. This seemed rather excessive to start as most sites are well under a gig in size but we figured they had all the original files within the source of the site.
Our next step now that we had everything backed up we started looking at the site and found that the reason the size was so big is it wasn't one site. It was actually five sites. For each resolution they wanted to target they created a copy of everything. Rather than using either Twitter Bootstrap or Zurb Foundation they opted to coding everything themselves. There's nothing truly wrong with that beyond taking a really long time to maintain a site in this manner (which was another client mistake). To add a new job posting they stated it took over two hours from start to finish with no interruptions. Not sure what their workflow was but we knew that was excessive.
After seeing the Adobe Muse mess we had seen we dug a bit deeper. No reason not to go further down the rabbit hole and see how far it leads us. The images on the site were truly beautiful and would be on a billboard (really!). The smallest image we could find was 5,000 pixels wide at 300 dpi. This was their logo that was only 350 pixels wide on the site. I guess they really wanted that retina resolution and expected everyone to have an ultra fast web connection.
We were now four hours into seeing this new project and we were beyond positive it was a nightmare. The site was functional. It did work on how it was created. It just was slow, poorly designed, and you could tell it was designed by a graphic design firm with no clue on usability or maintainability and written exactly the way you would learn in college or watching a beginners course on YouTube. We were definitely given a nightmare of a project to deal with. The client gave us a budget of 240 hours for their fixes based on how long it took the previous company. We opted to take this big project and "fix it". We told them we would throw out their 240 hour estimate and would re-write the entire project in 60 hours, it would load faster, and their maintenance would drop. We normally do not promise but after seeing what we have seen we knew we could provide a much better experience using the latest internet technologies. We're pretty smart and we refuse to ripoff our clients and chose the side that would give a great customer experience, save the customer money, and make maintainability a lot less painful.
Thirty-five hours in and the site went into test with the client. When they first looked at it they were in shock as it loaded quicker but also didn't look any difference from the old site. They thought we just did the changes they wanted and were pulling the wool over their eyes. As we continued with them we showed them the administrative interface. and they knew it was a completely new site. More on that a bit later.
The results were beyond shocking. We knew we would be a lot smaller in size but what we found was insanely smaller. The fastest page before took 15 seconds. Yes, Google really hated this site for sure based on the speed let alone now optimizations for the search engines. Now the slowest page is averaging 2.7 seconds which is quite acceptable. I think the biggest eye opener on the entire project which now has more images and pages is only 291 Meg, not Gig, in size or 305,818,648 bytes. This means the new site is 1.33% the size of the old site or 98.67% smaller. We didn't remove any pages, images, or documents. We did add more pages, documents, and images as part of the project. We just made images the right size, optimized the site load time by using better techniques, and finally added a CDN (which is factored into the new file size total) to make everything a lot more efficient.
Now what about that two hour job posting creation time? Well, we know our own software solution but we did enter all thirty jobs they had in the thirty-five hours to rebuild the entire site so. We also had the client work on doing the same steps and they entered a job start to finish with us explaining what to do in less than ten minutes.
Adobe Muse was and is a great product for proto-typing but definitely not large scale site use. Add to that that the product is being retired it is time to start looking at upgrading. We were thankful for this project as it allowed us to truly make a difference for this client but also show some of the heartaches a lot of Adobe Muse sites face. This was no where near our largest Adobe Muse migration but definitely one of the most poor designs we have seen in the past five years.
Problems with Adobe Muse
Adobe Muse has been around a considerable period of time, colleges have been teaching it to aspiring graphic designers and web developers for years. As software developers we love to use it for proto-typing. Proto-typing is when you want to showcase something in a quick design but not go into a production environment. Too often we see these sites go into production. The above example is just one reason why we don't like Adobe Muse. There are more problems that we, as developers, see and these are our personal opinions based on using the software for the past five years.
The problems we have with Adobe Muse is:
- Not 100% standards based. We find too many oddities that just don't work with all the latest desktop, tablet, and mobile technologies.
- The code is unreadable. That isn't a true deal breaker but if you are creating something you want it to be easily read and maintained. As an example we had one page that was 7,599 lines of code in Adobe Muse and in HTML5 (the re-write) the same page was 2,024 lines of code.
- Maintainability. Specifically on larger files the editing and compiling of the site can take 10-15 minutes for even the most basic of changes.
- Lack of a functional content management system.
- Note: Adobe Muse does give you an "interface" via file transfer protocol (FTP)that is web-based but severely lacking compared to modern content management systems (CMS).
- Lack of "real" search engine optimization or SEO. You get the most basic of SEO that was valid back in 2012. To add better you are looking at a nightmare to maintain. You have no structured META data, custom META data, etc. that helps you integrate with social media, the latest search engine standards, etc.
- No real native way to create a sales funnel process to use your website for creating sales.
- You have to "buy" a license from Adobe and install it on your local computer to have full functionality.
I know many people will not agree with all the above. Especially, those without any development experience, our graphic designers, and maintain Adobe Muse sites. The key to all of those is we all have differing opinions and views. As a final nail in the Adobe Muse coffin of this article is that Adobe Muse is on "End of Life" which means it will soon be dead by Adobe. On March 26, 2018 Adobe announce that on March 26, 2020 the product will no longer be around. There has been talk and some other dates thrown around going to 2022. Either way the writing is on the wall.
Adobe Muse End of Life Information
{{BLOGDETAILVIDEO}}