When looking at all the screenshots, it’s clear that padding and alignment is neither professional (looks amateur), nor consistent.
If you’re going to rip off Apple, at least do it to Apple quality! Otherwise it’s a cheap knock off. Before people grip that this is free software, would you be happy if KDE’s core components were poorly written? Free or not, we should take pride in our work and put the bar at high quality.
Just har a look at this as well as the fine article. Colors are similar but that's about it in my non designer opinion; even the colors are different as the ones from Apple seems to be somewhat translucent (kind of like Vista IIRC ;-).
Lack of horizontal padding? What padding do you want? There's clear whitespace between everything.
I for one definitely like and want more compact information. I definitely do not like the trend for making information more sparse. Leave that for your blog; business runs on information.
The most egregious example that stood out to me here is the x-padding between the edge of the notification panel and any text inside the panel is less than the padding between the notification title and the text below it.
The problem isn't that they need more padding, it's that their padding makes no sense. If they made a design decision to have tight padding that would be one thing, but they've got a horizontal layout with tight padding in the horizontal direction and wide padding in the vertical.
here's a really quick-and-dirty edit to even out the padding around each text block to be equal to the line height, which actually tightens up the total density by correcting the too-high line height in the notification text: https://imgur.com/uVcY6Sw
Programmatically, that assumes that that information is available (query a font rasterizer: where is the first pixel? consider also kerning and foreign languages; also query icon: where is the first non-background pixel? consider also theme information where window background might not show the icon well!).
Programmatically, you've un-aligned everything: now the amount of whitespace at the top of the notification is different than the amount of whitespace on the left of the notification.
Sure you might say it looks better. But how much time do you think it would require to make it look "pretty" (for you)? As-is, it's functional and isn't ugly. If you want to improve it, then go contribute to the libraries and applications being used.
As you’re keen to point out regarding everyone else’s comments, that’s your opinion.
Personally I think it’s functional and ugly. They could skip the drop shadow, the subtle transparency, the big icon on the right, the rounded corners, and just draw a white box. As long as they fixed the left padding it would look better than this.
Lots of attention to detail on the wrong things before they have the basics, IMO.
Then the vertical padding should be reduced. As it is, they're inconsistent and looks bad. I really want to like KDE and I used KDE 3, KDE 4 (from 4.8, since every version before that was a shitshow) and Plasma 5 for a long time as a main driver and is still my go-to in my backup laptop; but the visual aspect has always been an utter failure despite the massive improvements made in version 5.
Information density is not hampered by the presence of proper negative space, on the contrary, using the right amount of negative space actually allows for very information dense layouts to still be readable. A good example is a traditional paper phone book
What you define to be proper is likely not what I define to be proper. It's certainly a context-sensitive opinion.
The amount and location depends on what you want to do. Yes, just like a phone book, it needs whitespace. A notification window is not a paper phone book though. A paper phone book typically has a lot less whitespace than we're discussing here, so I'm not even sure if you're agreeing or disagreeing or trying to point something else out.
I also noticed that, came here to comment precisely the same thing.
I think the problem might also be exacerbated by the fact that the padding doesn't seem to be scaled based on DPI. (Unlike line height/icon size) So it looks acceptable on a low resolution display, but super close to the edges on a "Retina" display.
Thank god I'm not the only one who is annoyed by that. I remember 1 or 2 years ago when I first installed KDE I thought I messed up the installation because the padding/margins looked so jarring, I was convinced there was something wrong with the UI theme.
I don't know how to explain. Those look exactly like the KDE notifications I see all the time, but they never looked compressed inside the window on my desktops. Instead, it always bothered me that they were too spacey.
I am not sure if there really is a lack. I mean, I think I see what you mean, but given the fact that those are notifications, they are probably meant to feel 'thin' to not attract too much attention.
Another factor might be that those small, focussed screenshots are just not the appropriate format to show how those notifications would look like in the context of a complete desktop.
But in the end, it is also possible that there is an unintended lack of horizontal padding.
There's something to be said for being in close proximity with a lot of other people working in the same profession. I came from working in tech for 8 years before moving to Silicon Valley and it's a world of difference.
In other words, Country Music will always exist outside of Nashville, but if you make Country music, Nashville is the place to be.
People don't move to Nashville or Hollywood to be near colleagues; they move there to "make it big". I'm sure the same is true of most who ingress into SV. At least programmers can move to pretty much any big city and find a job paying upper middle-class wages (and can do pretty good living anywhere with decent Internet working remotely)
More on that point. The reason you cannot use if/else within JSX is because the statement needs to evaluate to an expression. If you really need to use if/else logic embedded, a ternary operator would work just fine.
I was hoping someone would mention this. Between this and an extended rant about `dangerouslySetHtml`, I would say this author was really scraping hard to find negative things about React. Poor quality article.
I haven't had to pull in jQuery for other things with usage of react-bootstrap, as react-bootstrap handles all of the interactions that bootstrap provides. Also, if file size is getting you down, and you don't need all of react-bootstrap, you can simply require the individual components you need.
I strongly feel that React Native is going to come out right around F8, but cannot prove it other than that the React team seems to be speaking there and this comment on twitter https://twitter.com/reactjs/status/573872611853123584
I'm getting pretty excited to start working with React Native either way.
Ran both through the Timeline in Chrome. It seems like there is a lot of time spent on scripting for Ember's version. In the underscore version you're consistently hitting render, but at least it's much closer to 30fps than Ember is in this scenario.
Not necessarily addressing the speed portion, but if you're going to give a key to a repeated item in React, it is best to use the index instead of a unique identifier(if the overall DOM structure does not change much between renders) so that React does not destroy and recreate each item on tree change.
funkiee, good catch on that issue. I just tried using the current index during iteration, instead of the actual unique ID of the search results item and that sped things up a lot. In fact, now React and Marko perform almost exactly on par for client-side rendering. Server-side rendering of React components is still very slow in comparison. I will update the README with the new results.
On a related note, the React docs were very misleading when they stated the following:
"In practice, finding a key is not really hard. Most of the time, the element you are going to display already has a unique id. When that's not the case, you can add a new ID property to your model or hash some parts of the content to generate a key."
Source: http://facebook.github.io/react/docs/reconciliation.html#key...
I tried following their advice and used the unique ID of the search results record and it turns out that was the wrong thing to do. It was better to use the index of the current iteration and I think that should always be the recommended thing to do given the performance difference.
The next sentence in your quote has some importance too, "Remember that the key only has to be unique among its siblings, not globally unique."
I agree there could be a little more clarity in that block of text, but I think the trade-offs section describes it well. Additionally, if there are any nodes in the tree that have a chance of being the same item between renders, you're going to benefit immensely from implementing a `shouldComponentUpdate` in your `SearchResultsItem.jsx` file.
React certainly doesn't win on every performance level, and if you try to compete on performance you're eventually going to lose. A careful developer could implement this list with no framework at all and have performance that beats both.
In the end, it's more about the mental model that best fits you and your team. I find the composite UI of React where I am building every component of other components in Javascript without a templating language to get in my way to be best suited to me.
If Marko works well for your team and you find it easy to get new developers on board and contributing code then that's awesome, keep up the good work.
funkiee, would you be interested in opening a Github issue or submitting a Pull Request if you believe that is the right thing to do? I'll give it a try in the meantime, but it would be great to have a public discussion on that so others don't make the same mistake (if it does indeed help). Thanks!
It's as intended. If the ID in a list of 100 changes, and that ID is the key, React is going to assume the tree is different during reconciliation. If you were to use an index, like 0, on pagination the key is still 0 and as such the DOM nodes will be reused. http://facebook.github.io/react/docs/reconciliation.html See #2 in the Trade-offs section.
I think the Front-End community just happens to collaborate a lot more than other communities and so the ideas get shared at a faster pace. Yes, it leads to framework churn, but it's mostly because we're learning from each other's ideas. If the other side of the coin is stagnation where people learn the dogma of a framework and not the reason behind it, I'm all for framework churn.
Find something that works for your team and stick with it. No one is making you use the latest framework or library out there.
