3

A client came to me with an existing site created in Adobe Muse by another developer. They had exported the site to HTML so I could post the files to the client's new hosting account. Now the client has a bunch of changes and I'm stuck with the unenviable task of editing the atrocious code Muse puked out.

I have a Creative Cloud account but have never used Muse as I code my own sites but I'm finding it unbelievably tedious to make site-wide changes to this inherited Muse site.

Every single element in the pages appears to have unique IDs. Removing any of them seems to break the site. Each page has its own stylesheet, in addition to a global stylesheet, most of which have styles for a long list of the unique IDs. This makes it frustratingly time-consuming and difficult to made site-wide changes, especially because all of this is then repeated in the 'phone' directory that duplicates everything for mobile devices.

The site is composed of HTML files. There are no includes for headers, footers, etc. so every single page must be updated with new contact info, header graphics, logos, etc.

Does anyone have any tips or recommendations for making this process easier? Can the site be made 'un-Muse-y'? Is there a convenient way to convert the unique sequential IDs to more semantic, global classes? Should I install Muse and import the site, if that's even possible? Or should I recommend the client consider hiring me to redesign the site in a non-fussy format that's easier for me and for them to update?

Improve this question
  • This may sound crazy, so please forgive me and stick with me. You will see where I am going. I have not worked with wysiwygwebbuilder.com, however, it sucks in HTML and translates the site to it's format and then pukes out it's own interpretation of HTML. It is not an HTML editor. It builds sites. I am thinking that if you use the trial version, you just may get a much less fussy but still semi-code-funky (did I coin a new term? semcodfunk vs.foocodbar) version of the site. It may be that MUSE is intentionally fussy to keep you hooked and to keep prying fingers out of their code. – closetnoc Sep 22 '16 at 22:56
  • Adobe definitely wants users of Muse to stay within that environment. I appreciate the suggestion but I'm not on a PC so I can't use that app. It might solve the problem for someone else though. – dugost Sep 23 '16 at 5:01
  • Okay. Just a crazy thought. Sometimes tools work for purposes not originally intended. I have saved my butt several times thinking this way. Good luck! Cheers!! – closetnoc Sep 23 '16 at 5:07
  • I was hired by a company to do the same thing. I almost finished three months later when they hired a frat buddy to do it instead. It only took him six months to replicate what I already had finished. They have another frat buddy who runs a whole company based on Muse. I will never understand the thinking that goes behind these things. – Rob Sep 23 '16 at 11:33
  • @closetnoc I appreciate the response. It's great to come up with workarounds like that which save time and prevent/alleviate headaches. :) – dugost Sep 23 '16 at 19:46
2

Oh Muse why do you do these things?

See this:

Muse is not intended to be a code generation hand-off tool for downstream editing. We recommend you do all of your site editing in Muse, rather than exporting the site from Muse and editing the code elsewhere. By staying within Muse, you can continue to use the full functionality of Muse to update your site. As soon as you move to altering the output of Muse, there's no going back (unless you're willing to re-make your changes each time you export from Muse). The HTML code output from Muse is not optimized for manual editing.

You may have but one chance and that is

Choose Object > Insert HTML. In the window that appears, select the default placeholder text and Press Delete (Mac) or Backspace (Windows) to remove it. Choose Edit > Paste to paste the HTML code into the HTML Code field. Click OK to close the HTML Code window.

For detailed Instruction you can follow the article here.

Update: That being said, I would simply explain the situation to the client and inform them that the person used a framework that is not intended to be used by other developers and no matter if they use you or anyone else, that they will have a serious obstacle for any and all changes and that a redesign in a more friendly framework should be considered. I would also worry that any functionality lost would look like you are to blame.

Improve this answer
  • Thanks for those references. I figured editing Muse sites outside of that environment would be difficult as the whole point is to remain within Muse.Your solution suggests installing Muse and replacing content via the Insert HTML option. This would involve me being tied to Muse, an app and environment I don't want to use. Nice to know there's the option but I'd rather have the client pay me to redo the site than to learn Muse and set up an old clunky site in it for future updating. – dugost Sep 23 '16 at 4:57
  • I agree and was going to comment that in my answer which I will do still. They are expecting way too much and might not be aware of it :) – norcal johnny Sep 23 '16 at 5:07
  • 1
    Thanks for adding that update. I hope it's helpful to others reading this thread. I explained to the client that with so many unique IDs and styles applied to elements which should normally be affected globally by a shared set of styles, it's like nightmare Paint By Numbers. In that, when painting 100s of green areas you'd normally only need 1 bottle of Green paint. With an exported Muse site, suddenly the 100s of green areas each have unique codes and a corresponding number of unique Green bottles. Meanwhile, the individual green bottles all have the same shade of green paint inside. – dugost Sep 23 '16 at 19:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.