Dev Diary Ep38 - What's New and What's Next?

Elements Dev Diary
1

Hello again,

In today’s Dev Diary I run through some of the new things in Elements beta 12, I also take some time to talk about what we’re going to be working on this week.

You can download today’s project via Elements Cloud to quickly test out the new scroll effects, have fun :tada:

Get The Beta

You can sign-up here to be notified when the Elements beta is publicly available.

Thanks

We’re listening to all your feedback and working super-hard to make Elements the perfect website builder :smiling_face:

If you have any thoughts about today’s Dev Dairy please post them below, we really appreciate the feedback.

See you next week :wave:

Thanks,

Dan & Team Realmac.

6 Likes
2

Looking forward to text formatting in an upcoming release. FWIW I’d rather have the text formatting bar at the top, along side the viewport size toggles as there’s already a lot going on in the bottom bar (node hierarchy, source panel, etc.).

3 Likes
3

We’ll take a look at the position and try it up top first. It’s a good suggestion as this would make it more akin to a traditional word-processor!

4

Top of my list for developing Custom Components is to fix editing Paste (Or double Paste as it is now) and enabling the CMD-V keybord shortcut. It has got so frustrating that I ended up editing my Custom components in a separate editor. :wink:

This would be closely followed by making the Dev Tools (?) available.

I would end up (for this list) by adding the revised Menu Component to the list.

However having said the above, it is amazing what we can actually produce at the moment. Keep up the good work. :grinning:

2 Likes
5

First of all, a huge thank you and kudos for the truly awesome work you’ve done on Elements so far! Your attention to detail and the innovative features you’ve implemented have been nothing short of impressive. :clap: :+1:t2: :tada:

Since you asked, a menu—a really slick, responsive mega menu that features both horizontal and vertical setups, accordions, drop-downs, off-canvas, and options to slide in, drop down, slide up, or overlay, Animated icons, along with custom hamburger designs, sticky, scroll to position and stick, oh, and one more thing, the kitchen sink. :joy:

The only other thing you already somewhat mentioned is a full set of keystroke shortcuts for text styling. Please include as many features as possible for all supported HTML styles, and map those to standard word processor commands. I see absolutely no reason to reinvent the wheel.

3 Likes
6

While I would not be opposed to the text formatting controls being on top (verse the bottom), I actually think, to maintain consistency, that they be located in the inspector on the right hand side, where all other controls for an element are located. My 2 cents…Thanks for all of the work being put into elements. This is actually the first web design software since GoLive 6 that I actually like!!

2 Likes
7

I agree, like Pages, very Apple like. Or both.

2 Likes
8

Yeah, I tend to agree. I’d much rather have the text formatting controls in the inspector at the side, like Pages, or Sketch.

9

I can see why you’d want them in the inspector, but it might feel a little odd…

The UI elements in the inspector control the overall settings of a component, whereas the text editing controls will only affect the highlighted text. My brain says it’s technically incorrect from a UX perspective. However, it might feel okay in practice, but I’m not sure. It’s probably one of those things that we just have to implement to find out if it feels good or not…

10

Interesting perspective. I don’t see anything different or wrong at all. It’s what I would fully expect from a WYSIWYG app.

11

I just meant the control position, not the controls themselves (those I think we need). Hah!

1 Like
12

I think it makes much more sense at the side from a UX perspective as it’s still a means of visually manipulating elements in the viewport. Creating another active toolbar for certain contexts will likely create confusion (just look at the Affinity apps in this regard). It’s also a very common design pattern on macOS.

I still think that using tabs (or segmented controls on macOS) within the inspector in order to group properties together (see Pages inspector for an example); such as style/format, layout, effects, behaviours, etc. would really help to provide a clear separations of concerns, making it easier for users to find the properties/controls they’re looking for.

2 Likes
13

I agree with Bryan, I think the top would make more sense. I’m assuming the controls would be conditional on what’s currently selected.

My only reluctance is it would look a bit odd in mobile view if the controls were anchored way off to the left with the page content in a strip down the middle (hope that makes sense). You could make the controls move with the page width but that would look odd.

In the Inspector would also be OK but it’s already quite a busy region (unless single group mode is on).

14

Excellent feedback on the text controls, thanks @bryanrieger, @sbchasin, @Flash, and @trinube :saluting_face:

Hopefully it’ll be obvious what the correct placement is once we get it into the app and can play around with various positions :crossed_fingers:

1 Like
15

Looking at Effects:

  • I’m wondering if there is a way to keep the controls from changing vertical position (ie jumping) when we select between ‘Start’ & ‘End’ state button & I’m sure it does it on other controls. I kept getting visually lost in the controls & got confused where I was when it jumped.
  • I couldn’t figure out why Effects and Scroll Effects only show on certain elements, maybe that’s because you only assigned those controls and those need to be added to the docs?
  • I wondering if Effects and Scroll Effects could be combined, as I’m really getting ‘control fatigue’ now :wink:
1 Like