Adobe Muse EOL announcement - Alternatives to Adobe Muse?

[Preran]

Hi all,

For those of you that haven't received the email around the Adobe Muse EOL, see the FAQ Product Announcement that tries to answer some the common questions around the announcement including the reasons behind the decision.

Before we proceed with discussing alternatives, the Muse application will continue to open on your computer. You will be able to continue to edit existing or create new websites with the application. Adobe Muse will continue to be supported until May 20, 2019 and will deliver compatibility updates with the Mac and Windows OS or fix any bugs that might crop up when publishing Muse sites to the web. However, it is quite possible that web standards and browsers will continue to change after Adobe stops support for the application.

While there is no 1:1 replacement for Adobe Muse at this stage, the FAQ link above provides some alternatives. Also, Adobe is making our own investment in DIY website creation and welcomes all Muse customers to join our upcoming pre-release program for a new format that will be introduced this year as part of Adobe Spark. Build a beautiful website—in minutes | Adobe Spark

That being said, I would like to open up this discussion for discussing other solutions and migration paths. It would be ideal if we could focus our efforts on the topic at hand.

Thanks,

Preran

[Illostraight]

FYI to new people:

List of alternatives for Muse

For Mac users:

Sparkle just updated their site again.

The EverWeb pricing is wrong, but I can't fix it on a mac.

Everweb > $199 per year with hosting / $99 per year w/hosting lite / $79.95 to buy Software only

[W_J_T]

Illostraight  wrote

Sparkle just updated their site again.

They better fix their main menu, as all the menu links now just reference /# . Unless that is a fancy new code-less feature to break menu links. 😉

In other news, the BlocsApp developer, released today how you can even use his new app SolisForMac with Sparkle. Which is pretty transparent and open to invite the users of BlocsApp competitive apps. Using Solis with Sparkle : Cazoobi Software Support. Interesting, but the BlocsApp developer is pretty unique as a developer, being very open, present and involved with his users on the forums, social media, and other direct communication channels.

[Studio96]

I was going to say that - sparkle menu goes nowhere!

[Illostraight]

Hopefully they'll catch it and fix it like all buggy releases. At least they're in there pitching.

[peterm47582768]

I am very impressed with Blocs. I'm finding it easier to use than Muse and just as flexible. The developer is hand on and the community are very helpful on the forums. Definitely with the investment in time and money.

[bernwa]

Thanks. It does look somewhat interesting.  i downloaded the trial.  It's not real intuitive so far but I'll watch some videos and check it out.

[Ekir75]

I have what probably is a stupid question.  If I build a website with Muse and put it online, can I edit that website with a different software or platform?  (Sorry-new to this)

[BenPleysier]

No questions are stupid!

When you publish a Muse generated site, you will need to convert it to HTML/CSS/JS in which case it can be edited with any text editor. The problem is that, once edited outside of Muse, you can never use the edited version in Muse.

[fotoroeder]

Ekir75  schrieb

I have what probably is a stupid question.  If I build a website with Muse and put it online, can I edit that website with a different software or platform?  (Sorry-new to this)

Not sure, if you have that in mind, too. You can edit it with Inbrowserediting (IBE). You can change images and text, you cannot add images and text or add pages, delete pages. Any content on masters is not editable in IBE.

You can use IBE on any platform around the globe as long as you have your credentials with you and some internet connection, of course.

Best Regards,

Uwe

[Ussnorway]

not all host servers are set up for IBE so if you host a Muse made site check that it allows IBE {some wordpress servers need a certain build}

[Nancy OShea]

Muse is a code generator.  In theory, exporting MU projects to HTML will allow you to work with the code in any code or plain text editor.  But  MU code isn't fun to work with.   You can try it yourself by bringing a MU exported site into Dreamweaver or Pinegrow and see how well you get along with it.

[greenskin]

Having had nearly two weeks of working with Sparkle (https://sparkleapp.com), and also discussing the near future with Duncan I have concluded that Sparkle (after the next big update) is going to be a serious contender for all us xMusers!

There is also talk of a prototype CMS integration in beta that will be a game changer for the free-standing application!

For the designers there is a copyright-free stock image platform integration with 1x, 2x, 3x, screen resolution with blur, filters (saturation, greyscale, invert, etc...), and more as default functionality!

Your site can be uploaded to your server of chose via FTP, or exported as html5/CSS3/javascript! The app is a one off purchase and desktop-based, but for most of you Windows users it only comes as a macOS application - sorry!

The generated html5 code is reasonable clean and not that much bloated. In other words it is a lot easier to work on code-wise then Muse is which can't be a bad thing!

There is so much more too it so the best thing you can do is give it a test run to make up your own mind and see how it fits into your business model!

[rayek.elfin]

Sparkle is interesting, yet the current version is inherently flawed for use in any team-based and/or medium-scoped web projects:

• the app insists on saving your project in its own proprietary file format. Muse does the same, and this makes no sense when the underlying tech uses open standards (html, css, js, etc.). Why not work with web files directly? It makes it impossible to integrate Sparkle seamlessly in an existing web coding pipeline, or us Sparkle to open an existing web project to quickly make some adjustments.
• when working in a team, the designer/front-end developer needs to publish the project before it can be used by a back-end programmer, or to extend it with additional functionality. Once this is done, it can't be easily read back into Sparkle for quick edits and adjustments based on feedback and user testing. The site needs to be published again. This is the result of Sparkle's own file format, and just complicates workflow matters.
• because of its proprietary file format, just like Muse, it doesn't play nice with other applications in regards to code: the user can't open a particular page quickly in a code editor to add specific features.
• While the html output is slightly more human-readable, it is still problematic that no standard is used (Bootstrap, Foundation,...) or more readable classes and html structure is generated. Again a big issue when handing off the code down the pipeline.
• Sparkle is only available for Mac. At least Muse can be run on Windows. Ideally all three platforms would be supported (Mac, Windows, Linux). Again, complicating working with a team, and a larger-scope project.

In short, Sparkle is a one-way application: design in Sparkle, publish in Sparkle, but no option for a team to use Sparkle in a two-way directed workflow. Just like Muse, minus the plugin ecosystem that allowed Muse to grow beyond some of its inherent limitations.

While I admire the developer's tenacity in creating a purely wysiwyg app, the fact that Sparkle insists on its own proprietary file format to save projects is by default SEVERELY limiting its usefulness in existing web workflows. It's a shame, really: I'd hoped the developer would have learned from the mistakes that the Muse Devs made. There is no reason not to work directly with the actual web files, aside from keeping the user encapsulated in Sparkle for commercial reasons.

As it stands, nice for quick prototyping and small-scale websites. Good for Mac-only designers interested in building simple websites without any knowledge of basic html and css.

I am biased (spoiled?), of course. I've integrated Pinegrow in my web dev workflow, which works directly with the underlying code, without the need for any awkward intermediary file format. The other day I converted a static site to a fully working WordPress theme within an hour!

[greenskin]

As mentioned there are some big and improved changes coming to Sparkle, but...

I hear you love the code side of things from what you wrote and what you say is correct in many ways, but from what I have experienced over these meany years is that clients don't care about the code that holds together their web site! What they care about is that it works across all devices and that it does the job they want it to do! It is us that are pedantic about the code!

And then we come to the real issues out there - table built websites! Yes they are still out there and yes Google still ranks them over well formatted html5/CSS3/javascript sites that are all well within Google's requirements! So it seems Google doesn't care much for the code either! Google cares about the content and how accessible it is!

If you are a coder at heart then Pinegrow is great, but I was talking to the xMusers who don't want to code but want to design and that is where Sparkle shines!

[Duncan Wilcox]

Sparkle is interesting, yet the current version is inherently flawed for use in any team-based and/or medium-scoped web projects:

• the app insists on saving your project in its own proprietary file format. Muse does the same, and this makes no sense when the underlying tech uses open standards (html, css, js, etc.). Why not work with web files directly? It makes it impossible to integrate Sparkle seamlessly in an existing web coding pipeline, or us Sparkle to open an existing web project to quickly make some adjustments.

Sparkle doesn't work with web files directly because HTML/CSS/JS do not convey enough information about the intent of the author. Once you go beyond a text block or an image, think of an image carousel for example, how many ways can you code that in? Probably at least 8-10 legitimately different techniques, and many variants of each of those.

Any WYSIWYG app that wants to insulate the user from code will need to "reverse engineer" that image carousel HTML/CSS/JS and infer that the original intent was in fact a carousel. It will have to scour the code to figure out if images are lazy loaded, what the transition time is, whether there's a loop, etc, and a lot of this is going to be in the javascript code. I don't know how much coding experience you have, but in computer science terms this is equivalent to the halting problem, which was proven to be an undecidable problem by Alan Turing.

Clearly the whole premise is that Sparkle wants to insulate you from code, you're using Pinegrow so you clearly have no problem looking at code and figuring it out. Sparkle is not working with code internally, and not hiding code from the user for commercial purposes, that's just the way things work out.

• when working in a team, the designer/front-end developer needs to publish the project before it can be used by a back-end programmer, or to extend it with additional functionality. Once this is done, it can't be easily read back into Sparkle for quick edits and adjustments based on feedback and user testing. The site needs to be published again. This is the result of Sparkle's own file format, and just complicates workflow matters.

I appreciate that for many instances you need this. Sparkle is not optimized for that, Sparkle is optimized for a visual interface with no code or coding concept on screen.

• because of its proprietary file format, just like Muse, it doesn't play nice with other applications in regards to code: the user can't open a particular page quickly in a code editor to add specific features.

While you can add an embed element and paste an HTML snippet in, for the reasons explained above there's no code under the hood. While I trust real web developers to be cognisant enough to make a quick additions to a page, Sparkle taking over code generation means it can ensure performance, compatibility and privacy compliance holistically.

• While the html output is slightly more human-readable, it is still problematic that no standard is used (Bootstrap, Foundation,...) or more readable classes and html structure is generated. Again a big issue when handing off the code down the pipeline.

Sparkle's code is not intended to be further edited, it's not something Sparkle users generally need. Furthermore if you pick two web developers you'll find they often have different coding preferences. You can't please everybody. Bootstrap and Foundation are probably "very popular" rather than "standard".

• Sparkle is only available for Mac. At least Muse can be run on Windows. Ideally all three platforms would be supported (Mac, Windows, Linux). Again, complicating working with a team, and a larger-scope project.

Agreed. Though, Linux...

In short, Sparkle is a one-way application: design in Sparkle, publish in Sparkle, but no option for a team to use Sparkle in a two-way directed workflow. Just like Muse, minus the plugin ecosystem that allowed Muse to grow beyond some of its inherent limitations.

Muse wasn't any different from a teamwork point of view? We lack a Windows version. We don't have Adobe-level resources clearly.

While I admire the developer's tenacity in creating a purely wysiwyg app, the fact that Sparkle insists on its own proprietary file format to save projects is by default SEVERELY limiting its usefulness in existing web workflows. It's a shame, really: I'd hoped the developer would have learned from the mistakes that the Muse Devs made. There is no reason not to work directly with the actual web files, aside from keeping the user encapsulated in Sparkle for commercial reasons.

Again there's no marketing or strategy behind using a proprietary file format. The tradeoff as it stands now is you either have a WYSIWYG, actually truly visual environment, or you have to understand code. And I'm not saying understanding code is a bad thing, just a lot more involved than what most people represent it to be, an infinitely tall slippery slope.

As it stands, nice for quick prototyping and small-scale websites. Good for Mac-only designers interested in building simple websites without any knowledge of basic html and css.

We have customers with 1000+ page sites, 100k visitors/day, tens of thousands of USD in sales per month. Sure the web is infinitely varied and web developer preference is as well. No problem with that. Your characterization of Sparkle's abilities are pretty wrong though.

I can't stress enough how "basic html and css" is a bad thing though. That is absolutely not sufficient to build more than a "small scale website".

I am biased (spoiled?), of course. I've integrated Pinegrow in my web dev workflow, which works directly with the underlying code, without the need for any awkward intermediary file format. The other day I converted a static site to a fully working WordPress theme within an hour!

Nothing wrong with being a full time coder and using the tools you find comfortable. More power to you. Building a modern website that appeases Google and the GDPR is not something you can do as a part time job these days though.

Duncan

[W_J_T]

https://forums.adobe.com/people/Duncan+Wilcox  wrote

We have customers with 1000+ page sites, 100k visitors/day, tens of thousands of USD in sales per month.

Let’s see some of these mythically fabled examples you speak of, as none are showcased or discussed on your site. Instead the examples you used to showcase on your previous home page were merely 5-15 page static sites (and looked like they were built with a framework​). Also it should be noted that some of those previously showcased sites you presented have since moved on and no longer use Sparkle for their sites which is more than interesting.

Surely people would be interested to see how these large examples handled creating modern responsive sites across 1000+ pages, since your own Sparkle site itself still has pages that are not responsive. So by all means provide some examples of these live public immensely successful sites made with Sparkle for people to review and be impressed with.

[W_J_T]

W_J_T  wrote

https://forums.adobe.com/people/Duncan+Wilcox   wrote

We have customers with 1000+ page sites, 100k visitors/day, tens of thousands of USD in sales per month.

Let’s see some of these mythically fabled examples you speak of, as none are showcased or discussed on your site. Instead the examples you used to showcase on your previous home page were merely 5-15 page static sites (and looked like they were built with a framework). Also it should be noted that some of those previously showcased sites you presented have since moved on and no longer use Sparkle for their sites which is more than interesting.

Surely people would be interested to see how these large examples handled creating modern responsive sites across 1000+ pages, since your own Sparkle site itself still has pages that are not responsive. So by all means provide some examples of these live public immensely successful sites made with Sparkle for people to review and be impressed with.

No example links to those 1000+ page sites Duncan ?

[GARRogers]

W_J_T

There is certainly some great design work being done by the designers on this forum who do websites professionally for others.

I have followed your comments here and I am sure from your posts that you must be very sophisticated at all this. Could we see a couple of your websites?

Along with sophisticated web designers here, there seem to be a number of artists and craftspeople who have used Muse.  Muse gave us a freedom to avoid the sterile boxy look of Wix  (and even Rapidweavver) and make sites that suited our needs. If we have been displaying our artwork for a while, chances are good that we have an idea of how we would like to do this. At this point we too are looking for alternatives to Muse.

For me personally, Sparkle is certainly one possibility to fill my needs.

If you don't like Sparkle, fair enough, but is it necessary to keep up your derisive tone?

I personally would like to see the app succeed. If it isn't for you, fair enough, but perhaps there are others whose needs it might fill well for reasons separate from yours. Surely constructive suggestions would be more in keeping with the spirit here.

Or, if you can't think of any, why don't you describe for us which of the alternatives you trend toward and why. It might be more helpful for us all.

[Nancy OShea]

GARRogers  wrote

...why don't you describe for us which of the alternatives you trend toward and why. It might be more helpful for us all.

Not W_J_T, but I'll chime in. 

My point of view is based on 20+ years of hands-on experience with both drag & drop web authoring apps as well as coding tools.  I can say without hesitation that understanding native web technologies (code)  gives you far greater freedom to create exactly what you want without being held prisoner by a closed ecosystem that might not deliver all the options you crave.   If your tools limit you to a strict set of options, that's all you will use.  Hence, you're following the heard instead of leading it. There's no growth potential unless you break out of that limitation in other ways.    Tools aren't talented,  people are. 

More importantly, native web technologies tend to have much  greater longevity.   That's not a put down to anyone, mind you.  It's just the facts.   HTML level 3.2 still works today much as it did more than a decade ago.   I can't say the same about  proprietary code from Front Page,  GoLive or other drag & drop web apps of the past.   Those sites are long gone or if not,  the app generated features they contained don't work anymore. 

Use whichever web apps & coding tools most appeal to you.  But if you want design freedom and longevity, learn all you can about native web technologies. 

Nancy

[Illostraight]

We understand this and it has been discussed Ad infinitum.

It's not worth it for people who don't have the time, can't keep up with the future changes and would forget it as they don't use it enough. So this discussion would be better spent with people explaining the pros and cons of the available apps, not challenges like some have made here, coding vs wysisyg. Let's leave comments about apps like Michelle and York have left for those that want drag and drop or for those that want to or can code. Much more productive, helpful and positive. Just sayin'.

[GARRogers]

Nancy O'Shea

Thank you for your reply. Your point is well taken and I understand what you are saying.

I actually learned enough html and css to code four simple websites. I liked doing it, it was fun to do.

But much more time-consuming than Muse is/was or some of the other apps discussed here.

Here's my problem and I suspect that of a number of other people who used Muse.

Making a website is necessary for me but it is the tail of the dog.

There just doesn't seem much sense to keep saying what's wrong with wysiwyg, I understand.

Within the limitations of wysiwyg, what is right with which apps?

[Nancy OShea]

GARRogers  wrote

There just doesn't seem much sense to keep saying what's wrong with wysiwyg, I understand.

Within the limitations of wysiwyg, what is right with which apps?

It's always a trade off though.  What one app gives another takes away.  And then there are UI/UX considerations all of which you must decide on for yourself.   I have yet to find the Holy Grail of web authoring apps or for that matter the perfect code editor.  As such I don't rely on any one tool to do my work for me.   I use many tools, the most important one being the old gray matter cells (such as they are).

[GARRogers]

Nancy O'Shea:

I have yet to find the Holy Grail of web authoring app

I'm not looking for the Holy Grail, just something reliable that has a chance to be around for a while (notice I didn't say forever) and is easy and quick to use. So far I have decided to try Sparkle.

I am still here because I would like to find a second app also.

It isn't about the difficulty of learning an app, it comes down to speed for every-day web maintenance, where content carries the day. Most of my customers don't care about the layout so long as they can navigate around the site easily; they come for the content. 

I don't think the choice not to code comes down to unused gray matter. It is about time and the allotment of gray matter to code or content. In my case content prevails.

[Duncan Wilcox]

My point of view is based on 20+ years of hands-on experience with both drag & drop web authoring apps as well as coding tools.  I can say without hesitation that understanding native web technologies (code)  gives you far greater freedom to create exactly what you want without being held prisoner by a closed ecosystem that might not deliver all the options you crave.   If your tools limit you to a strict set of options, that's all you will use.  Hence, you're following the heard instead of leading it. There's no growth potential unless you break out of that limitation in other ways.    Tools aren't talented,  people are. 

Thanks for your thoughtful reply Nancy.

I too have been working with web tech since 1993. I have written web servers, custom Apache modules, CGI scripts, bare HTML pages, table+gif layouts, fought with IE, you name it.

What has changed significantly in 20 years is the breadth and scope. It used to be possible to hold all technologies in your brain, know the browser bugs, pick tradeoffs. I do think this has changed to a point you can no individual can do it all anymore. You need to rely on some tool or abstraction. This change isn't even recent, but the pace has been speeding up in the past 10 years or so.

For example many web developers rely on bootstrap, because it takes care a class of problems that a web developer no longer needs to think about. It helps you cope. More importantly most web design projects wouldn't be remotely possible, from an economic point of view, if you couldn't rely on a bootstrap to solve the responsive aspect of a website for you.

In a way bootstrap is holding a web developer prisoner as well, you feel free to move within the bounds bootstrap is making it possible/easy to do, but it's fine because bootstrap is something you chose. I think this can be said of any tool, including visual tools.

This argument is valid for dozens of areas of website building, each of which requires its own tool, if a tool even exists:

• using css vs sass vs less
• responsive css and testing viewport widths
• markup/style/code separation, progressive degradation, accessibility
• using jquery vs plain javascript vs transpiled javascript vs web assembly
• image format, responsive images and display densities, image compression and specific tools, lazy loading
• critical css and render blocking content, deferred loading of css, js and web fonts
• animations and dynamic content changes vs rendering and DOM performance
• handling cache lifecycles across site updates to ensure long term browser caching and quick updates when needed
• testing on arcane mobile browsers
• SEO tagging and limitations, metadata and micro formats for sharing and search
• leaking visitor data, referrer and content security policy, content embedding and cookie banners, GDPR requirements
• server configuration for compression, caching, redirects, mime types, SSL (certbot) and transport security

All this is before even looking at anything content, marketing or advertising related. That's quite a bit more than knowing what <p> or padding-left means, and is in large part necessary to comply with regulation and have any chance of being visible on a search engine or social network.

Now you can place your threshold at knowing html and css, or at knowing bootstrap, or at knowing tools build on top of that, but you can't know it all. What's certain is a higher level tool has many many hours of engineering time poured into it, with the goal of solving real problems and having a more consistent approach to a problem. With that come some restrictions. You drive on asphalted roads to get to places faster, even though sometimes you need to drive longer than going straight to where you want to go, through fields.

I totally get being fascinated with one aspect of all this, and focusing on that. On an infinite timescale we want to dive deep into first principles with everything. Alas time is always finite.

Duncan

[W_J_T]

https://forums.adobe.com/people/Duncan+Wilcox  wrote

All this is before even looking at anything content, marketing or advertising related.

Regardless of tool, method or workflow, you are suggesting people should be concerned with such things as browser caching before content in the build process ?