Designing Around vs. Designing Into

Elements
1

I’ve been doing a lot of prototyping with Elements, and it’s turning into a robust program, but one with a flaw for my (and many others’) use.

Designing the most common Landing Page scenarios is simple, easy, direct, and best of breed. Fixed page sites are simple enough to build.

But this is about designing things to appear around/next/above/below each other. The Bento box “fad” currently on the forum is a great example of that: Elements can do that with its eyes closed.

But that’s not how all Web sites work. Most of the time I design within Articles, and here Typography is truly flawed. Many of us have argued for it to support lists from the beginning, but “lists are coming [in some other component]” later. No. That’s not how I add to my sites (e.g. add a page via template, write some text in a component, get to a point where I need a list, then drag in a list component, then drag another text component in to continue my writing. Ditto for video, image, pull quotes, you name it.

No, I want an Article component within which I can insert list, image, video, quote, et.al., as I’m writing. Generally, that component is also a “page filler,” meaning that it lives in a pre-defined (from Template) container that usually is site width (with padding, etc.). As much as Sandvox was maligned, the thing it got 100% right was this part (page from template, write and design within what you’re writing).

Now the CMS starts to address this problem, but without the .MD creator/editor that understands lists, images, et.al., I’m still having to deal with write, fiddle around with the non-text thing, write, fiddle around with the non-text thing, etc.

I’ve now got a design I like a lot, but simply am not anywhere near being ready to commit to Elements. That’s because the project(s) I need to tackle are thousands (probably tens of thousands) of Articles, and so I’m at a stopping point because (1) There’s no Article component as I suggest needs to be built; and (2) The CMS is fragile and it’s not clear that effort I put into that direction today will pay off tomorrow, as I suspect we’ll have changes down the line, and I can’t afford to have to go back to thousands (or more) assets and fix/align them.

1 Like
2

Not sure i understand what you’re saying… inside a text box you want to insert pictures and video?

3

I want to create an Article. To do so:

  1. New (designed) page from Template.
  2. Start writing in Article component.
    1. Insert images.
    2. Create lists.
    3. Create headers.
    4. Create quotes.
    5. all done without leaving Article container.
    6. continue writing as I intersperse the above.

If there were a Markdown component, I could probably do this (of course that introduces how you type MD and see WYSIWYG). Again, Sandvox did this correctly (without the Markdown).

Some of us use Web site creation products—think publishers—as word processors that display the results externally. It’s one of the reasons why Wordpress took off, as it basically acts that way (though there’s a lot of tinkering you have to do behind for styling/organization, etc.). It very well may be that Elements eventually acts that way through the remote CMS editor. But it doesn’t come close to acting that way today.

4

Typography is still a work-in-progress. Everything has to start somewhere, and the good news is that more features are coming… including list support :wink:

I think the CMS with Markdown support will open the door for much of this. Once that’s in place, you’ll have far more flexibility in mixing lists, images, videos, quotes, and more.

If you’re dealing with tens of thousands of articles, that really calls for a database-backed system. A desktop web design app isn’t the best fit for managing that kind of scale.

Elements in its current form isn’t going to solve your needs today. That said, as the CMS matures and we add third-party integration options, it may well become a viable solution for you down the road.

Worth keeping an eye on Elements, it’s come a long way compared to where it was even six months ago!

1 Like
5

Good to hear. Thing is, a better typography solves a lot of problems.

I think the CMS with Markdown support will open the door for much of this. Once that’s in place, you’ll have far more flexibility in mixing lists, images, videos, quotes, and more.

I have no doubt of that. I’m looking forward to that, but it’s still a ways off from production use.

If you’re dealing with tens of thousands of articles, that really calls for a database-backed system.

These sites don’t start that way ;~). But I’m reluctant to even start my small one with the current situation.

A desktop web design app isn’t the best fit for managing that kind of scale.

Strongly disagree here, as that’s what I’m currently doing ;~). The problem I have is that I’m doing it in a virtual OS now; the product didn’t make it to current macOS.

6

I 100% want to hear about this setup with ten of thousands of articles, what old macOS app is this? I wonder what we can learn and take from it :thinking:

1 Like
7

@dan I’m wondering how this would work, as currently, to get the Markdown rendered from a CMS file, you have to publish it to a Typography component, so if that component does not support something, you are not going to get it. For all this to work, it seems the first thing that needs to be completed is the typography component.

Without support for lists in typography, for example, any lists I set up in my CMS files are not going to render. Unless, at some point, there is going to be an actual Markdown component that respects all of the Markdown capabilities.

8

I’d love to see a markdown component too. Though maybe that might not even be necessary, if the typography component would be markdown friendly.

But hey, that might be coming.

9

I can’t be the only one curious to see either the web site or a sample of the page/layout described. I’m having trouble picturing it.

1 Like
10

Before getting to my sites, I want to say why I think it’s important to get Elements right.

The days of SEO are over. If not completely over today, then soon. By that I mean that I build a Web site and, at least in partial, hope that people find it via search engines. If you haven’t been paying attention, AI will takeover search and spill out the answer instead of a link to your site.

Why? Because “follow the money.” Google doesn’t really want you to leave Google any more, because if you do get to another site, they lose some control and tracking of you. They have to monetize virtually (tracking, to be applied when you come back to Google’s sites). If they could just keep you in the Google domain—and remember, that’s Android, Chrome, and AI ne: Search—they could serve all ads and push all commerce. Meta does something similar within their social networks, and wants to do the same thing (keep you in their domain, not let you out to another).

If your site relies upon search for people to find it, that won’t work in the very near future. Thus, making a pretty, mobile-first, SEO-friendly Web site really shouldn’t be the primary design goal anymore. What works is building communities. It’s always worked, if you were paying attention.

Okay, to my sites. They are currently done in Sandvox (!) with a fair amount of CSS arm twisting to make them mobile semi-friendly (menus are still a problem). They consist of filmbodies.com (Nikon film SLRs), dslrbodies.com (Nikon DSLRs), zsystemuser.com (Nikon Z System cameras), sansmirror.com (mirrorless cameras), and bythom.com (general photography and the aggregator site. Together they have well over 1m uniques a year, and a pretty persistent 100k+ constant user. If you look carefully, you’ll see that these sites are broad and deep. Periodically I’ve had to re-arrange the menu structures to keep the width down and the depth negotiable. Amongst the sites there are now tens of thousands of pages, some dating back to 1988 (not all are still exposed in the menus).

I’m currently on semi-pause with those sites, as what I want to do with them requires a complete change in how they’re built, which is why I’m looking closely at Elements. I actually believe that, with the right additions and changes, I could do what I need to do with Elements. The CMS really changed that, particularly with it’s Markdown-centric ability.

I’ve already prototyped the smallest site using Elements, and I like it. It’s cleaner, fresher, better, and likely easier to maintain than the current iteration. But I can’t deploy with the current typography component or the finished CMS without a lot of grief. The reason for my post was to encourage you not to get too carried away with the Landing Page design mentality things—again, they’re not going to be as useful in a searchless future—and put more attention to what will keep a site healthy through the next decade. The CMS is part of that, but the unfinished typography is a glaring issue, too.

As for what to learn from Sandvox (!): they did a number of things right. Once I figured out the responsive bit (with help from Charlie at Blueball), I can live with (1) pull a new page from theme into the page structure, (2) enter content directly on the page, (3) post. One drawback (and benefit) of Sandvox is that the entire site has to repopulate on publish, which given that the total assets are 500MB+ takes time.

1 Like
11

used these sites a lot of times over many years, when deciding on next camera, then next ,then next, excellent reviews/articles

can see why the functionality is needed

12

What we do need for elements is the functionality of this stack: Home | Scribe Stack for RapidWeaver

I bought the pro license of Elements as I am convinced about the potential, but the lack of a good Text component is currently holding me off from transferring my sites from Stacks/RW to Elements.

In my view, Text is the most important part within creating sites :slight_smile:

Cheers,
Jan

2 Likes
13

I wasn’t aware of that Stack, but yes, I’d agree with you. If typography or another component did that in place, we’d be fine.

14

For me, the addition of something like the SCRIBE stack would be the crowning glory for Elements. That was my most-used stack when I was using Classic, as it did everything you could ask of a text system, and puts the typography stack to shame.

I have never understood why the typography stack was not a higher priority with RM, as it is such a critical part of a web development system.

I find the whole typography system very limiting, and it has some serious drawbacks, not the least of which is the fact that you cannot package the settings with the component in a template. Sure, I understand the attraction of the current system from a theme-switching point of view, but the reality is we need to add content to our sites, and it is a pain to work with the current approach. I have been asking for a Markdown component from the beginning, but it does nto appear to be a priority, which is a shame.

I wish we could talk to the developer of Scribe about porting it to Elements.

3 Likes