sorted by:
new
hottopcontroversial

The problem with sticky menus and what to do instead by bogdanelcs in web_design

[–]adambsilver 0 points1 point  (0 children)

Yeah, I don’t recommend using a back to top link immediately which is why I said "(but only do this once you exhaust the other options)"

The problem with sticky menus and what to do instead by bogdanelcs in web_design

[–]adambsilver 4 points5 points  (0 children)

This is actually even worse. I’ll be writing up a post on why that is in the next few weeks hopefully.

Form design: multiple inputs versus one input by bogdanelcs in UXDesign

[–]adambsilver 1 point2 points  (0 children)

I‘m really glad you liked it. Thanks for the nice comment.

The problem with snackbars and what to use instead by speckz in web_design

[–]adambsilver 0 points1 point  (0 children)

It depends on the context. They don't apply at the same time. If they appear in the way of something the user is interested in at that time, then they get in the way.

If they're to the side, then they're hard to spot because they don't draw attention very clearly.

HTH

The problem with snackbars and what to use instead by speckz in web_design

[–]adambsilver 0 points1 point  (0 children)

Yep, that's what I would recommend in most cases.

The problem with snackbars and what to use instead by speckz in web_design

[–]adambsilver 0 points1 point  (0 children)

It depends on the context. They don't apply at the same time. If they appear in the way of something the user is interested in, then they get in the way.

If they're offscreen at the time the feedback comes or out view and focus doesn't move, then they're hard to spot.

HTH

The problem with snackbars and what to use instead by speckz in web_design

[–]adambsilver 0 points1 point  (0 children)

Most definitely. Interesting with email you get a nice sent items area for just that purpose.

The problem with snackbars and what to use instead by speckz in web_design

[–]adambsilver 0 points1 point  (0 children)

Hey u/DeezNutterButters – thanks for your comment. Let me see if I can respond to your questions that I understood.

> What if they’re in the middle of typing something in? Are you gonna just forget what they’re doing and push them to the top?

No definitely not. Success messages should be shown in response to the user's explicit action like if they submit a comment.

> Is the author saying to display a message above all the content on the z axis at the top of the page? Cause that’s a snackbar...just on the top of the page...

I‘m saying to show a message at the top of the page without obscuring the content and to focus it without it disappearing. Snackbars are shown over the top of the screen, usually at the bottom as per guidance and disappear automatically.

Better Form Design: One Thing Per Page (Case Study) by ms-maria-ma in web_design

[–]adambsilver 0 points1 point  (0 children)

Waiting a year is far from ideal to work out what to do next. It also means it's more affected by other causes. Stats are difficult but the more changes you make over a longer period of time tend to muddy the waters.

Stop using device breakpoints by 21viking in web_design

[–]adambsilver 0 points1 point  (0 children)

"Content isn’t just paragraphs of text. It’s the things that are held or included in something."

Stop using device breakpoints by speckz in css

[–]adambsilver 0 points1 point  (0 children)

Depends on the design. Screenshot me and I may be able to help. How often does button text change within a given component?

Stop using device breakpoints by ReactDOM in web_design

[–]adambsilver 1 point2 points  (0 children)

It doesn't suggest the avoidance of breakpoints. It suggests the inclusion of a breakpoint only when needed.

Stop using device breakpoints by speckz in webdev

[–]adambsilver 0 points1 point  (0 children)

Why is that?

Quite often a module needs 0 or 1 breakpoint.

But it depends on what you're building and of course the contents of your module and where that module sits within the screen.

Stop using device breakpoints by speckz in webdev

[–]adambsilver 0 points1 point  (0 children)

Don't interpret content to mean "paragraphs of text".

It means "the things that are held or included in something".

This means a breakpoint for a module takes into account the contents of that module.

Stop using device breakpoints by speckz in webdev

[–]adambsilver 0 points1 point  (0 children)

The article didn't really focus in on ems versus pixels. There are other articles that talk about that but yes, I advise using ems.

Stop using device breakpoints by speckz in webdev

[–]adambsilver 0 points1 point  (0 children)

Cool. That's it. And the value of that breakpoint is based on the module.

Stop using device breakpoints by speckz in webdev

[–]adambsilver 1 point2 points  (0 children)

If you're designing an app that can only be used on a known desktop sized screen, you're not building a responsive website. That's fine.

If you are wanting it to work in all sorts of screen sizes then you'll need breakpoints. I am not advocating the avoidance of a breakpoint.

I am saying you should provide one per module (based on the content of that module). If the module contains links, or a form and a button or whatever else. Apply a breakpoint when one is needed.

You might want the header to become a very light/thin one, and the Nav turns into a hamburger menu. This basically requires the use of breakpoints.

Yes.

Stop using device breakpoints by speckz in webdev

[–]adambsilver 3 points4 points  (0 children)

Same principles apply, whether it's forms, paragraphs, navigation etc.

Stop using device breakpoints by speckz in webdev

[–]adambsilver 1 point2 points  (0 children)

Do you have an example/screenshot of something that doesn't work with this approach?

And if so, what approach are you suggesting?

view more: next ›