Designer News
Where the design community meets.
UI/UX Engineer at HackerOne Joined over 8 years ago
Jens hasn't posted any stories yet.
I hate to say this, but this is one of the worst typefaces I've seen. Some of David's other typefaces are amazing (love Turnip, Fern & Gimlet), but this one is totally unreadable imho, although you can see it's crafted with care.
I'm not sure what the ruckus is all about. So the author puts up a graphic for its buyers to use, Chris Brown (his management) purchases it with the rights to not give credit, and people complain about the buyer not giving proper credit? Chris Brown should not be treated less equal as other buyers, it's his right to not give credit.
I'm equally astonished by all comments about a (debatable) high end music performer using a template. As if custom is always better than something meant for mass usage. It's not a shame to use a cheap template, it's smarter than putting up $10.000 dollar for a super custom cover that doesn't necessarily look better than a cheap graphic on ThemeForest. Especially when they think it looks great and does its job.
Cool little app. I would highly recommend writing in English for the description and the changelog–it's putting me a bit off. I would also put a couple of unique selling points into the description to explain the user why they should use it instead of going to the WIFI Preferences?
To conclude: your problem isn't the app, it's how you advertise it. Good luck!
Hi Sharav,
I think Gabriel's and Jesse's comments are pretty accurate. Although I have spent only 5 minutes on this with Chrome's Element Inspector, I have hacked something together for you that should put you on the right track:
Screenshot of a direction you could take: Bigger screenshot: http://imgur.com/a/B2ft1
Good luck, Jens
It is so frustrating not being able to scroll down, while the design indicates I can. I want to see more about the product. More information, more screenshots, more features. There is just not enough to go on. I only see a title of a proposal with a nice background. What's easier about using your product to make proposals? Don't say it, let me see!
I think LESS/SASS changed the way we write CSS, and I think that's not bad. It's the same how I feel about BEM: it has changed the game, but for the good. Especially now that SASS has a tighter integration with BEM that allows us to write BEM like this:
.component { // Style &__element { // Style } &--modifier { // Style } }
which compiles to this CSS:
.component { // Style } .component__element { // Style } .component--modifier { // Style }
Great things are happening in the world of CSS.
I wholeheartedly disagree with most of these points, mostly because they don't fix the problems he stated. Let me comment on your statements point-by-point:
Think in components: I agree with this one:)
Child elements of component should only have one word: I don't think this is a very scalable solution:
.search-form .field
it first looks for all .field
classes, and then looks at .search-form
..title
could match for hundreds of CSS elements, while .search-form__title
will probably match only one (if not, you didn't name your code correctly).Instead of this, use BEM. This creates a readable format for CSS classes that is easy to search, requires no nesting and is very fast. Clashes are a thing of the past.
One component per file: Although I agree, I do think it's better to not just throw all components in a single "components" folder. With a large codebase you will probably get different types of component, which you might want to split up.
Use @extend to simplify nested components: This is another pitfall of just using single-worded CSS classes. Use BEM for this and make sure you're using @extend
in the way it was supposed to: http://csswizardry.com/2014/11/when-to-use-extend-when-to-use-a-mixin/
Avoid over-nesting: This is ironic, because your tips creates the problem of over-nesting. Your proposal is a hack that can be prevented by using something like BEM.
But dashes suck: No they don't, but that's probably a personal preference.
Solutions for the stated problems: The following problems were stated:
Any CSS greater than 1000 lines will get unwieldy. You'll eventually run into these common pitfalls: 1. "What does this class mean?" 2. "Is this class still being used?" 3. "If I make a new class green, will there be a clash?"
Solutions: 1. Use BEM and common sense to name your CSS elements. If you don't understand, you're not naming your elements right. 2. Fix this with automated linters and integrate this into your CI builds. Or just do a quick search with your code editor. 3. Not if you name your elements correctly.
I am not saying Soundcloud's current UI is that great, but I think the proposed design in total is a step back from the current one. I think you can make some great improvements with a few iterations from the proposed design. It's a good first proposal, but it needs some extra thought before having a design Soundcloud could actually release to users.
I think it's great Evan (the person who made the proposal) spent time to improve Soundcloud's design, but so the team at Soundcloud did. The downside of Evan is he probable made this all by himself, so he didn't get the luxury the Soundcloud team has of feedback from colleagues/peers.
That's the main general issue there is with most redesigns people do: they lack the experience the product team gathered from users and the knowledge from problems the product team already encountered. And it's just a lot harder when you're on your own, without insights other people have.
Outside people like Evan do have the advantage of having a fresh look on things and experience with the product – something that the product team will lose after a while because they are so into their own product they don't see things anymore (like banner blindness). You can definitely see that in his design: an entirely new direction that the Soundcloud people could definitely combine with their experience and knowledge of the product.
For example, the introduced blur would be a great addition to display behind Soundcloud's current promoted song with the big graphic behind the graph. And there are a couple of other things the Soundcloud design could really benefit from, but the problem is that Evan tried to create an entirely new design without keeping some of the current design's elements that do work good.
I really like the effort, but I do not think this is better then the current Soundcloud design. Yes, it is aesthetically more pleasing, but I think you made some big errors in terms of usability and user experience. Let me explain:
Although I like the player in the topbar, I think there are some issues with the topbar concept:
Let’s move on to your content. Like the colours used, and the blur is nice too. There are a few problems though:
So to summarize: great looks, but you’d trade in a lot of user interactivity, usability and experience for it. Hope you take this as positive feedback☺
Jens hasn't upvoted anything yet.
Designer News
Where the design community meets.
Designer News is a large, global community of people working or interested in design and technology.
Have feedback?
This does not make sense to me at all. Why should we not criticize something that's meant to be read for its readability? A product should not only be criticized on a single aspect (aesthetics in this case).