Interestingly they've built two different versions of the typeface: Compact (for watchOS) and UI (for OS X/iOS). Compact is far closer to DIN or Roboto (with flattened vertical strokes on glyphs like the uppercase C, D and G), whereas UI is far more rounded, and looks a lot like Helvetica for some glyphs.
I was concerned based on what I'd seen of the typography of the Apple Watch that it'd be too cold and characterless (I really dislike Roboto on Android) to use across OS X and iOS, but by creating this separate UI variant they're able to make it feel like a gradual transition from Helvetica Neue. It's so similar, in fact, that I'd not be surprised if we end up seeing more font quizzes asking: ‘Arial or Helvetica …or San Francisco?’
The mechanic itself isn't actually that interesting. When they released the demo there was a discussion about how the mechanic works over on the destiny.bungie.org forum: http://destiny.bungie.org/forum/index.php?id=15007 — in a nutshell the time pausing mechanic doesn't really make the game a ‘puzzle’: it just lets you pause the game arbitrarily to let you line up your shots. This is why other shooter games (F.E.A.R, Max Payne) that have let you slow down time do so with finite resource mechanics to prevent overuse.
If the developers implemented any more interesting mechanics that let you rewind time, or made some enemies immune from time pausing then this might become an interesting game, but based on the demo it just looks like a shallow but pretty game, and is unlikely to be that much fun.
The time pausing mechanic also lets someone who has not played FPSs for half their life have the experience of being a god-like player who avoids all shots and gets a head shot every time. As someone who normally hates first person games and has no interest in practicing them for months on end, this is cool.
Yes, this really seems like it's an FPS intended for non-FPS players. I think that's the whole point - the game basically says "let's eliminate all skill from the FPS game and make it into pure strategy and see if there's a fun game there".
That's an interesting question - once you can nail every headshot, plan every evasion, and spot every foe with complete ease... is an FPS still fun? Can it be made to be fun?
Obviously, for an FPS fan for whom the skill is a core part of the gameplay, this might not be an interesting question for them.
Is it an option? I think if you move the time moves as well. If you aim badly you still need more time to get it right. You can just take a break in the middle by not moving at all. At least that's how I understood it.
In the original 7-day prototype, time moved at a crawl if you stood still, and accelerated to normal speed when you moved. Changing the view with your mouse did not count as "moving" so you have a lot more time to line up a shot. Of course you also have to contend with travel time of characters and bullets, which is not a wholly trivial task.
I think this is a good point. F.E.A.R did this amazingly well in the first instalment, and the way that the enemies worked with cohesive group strategies was pretty ground breaking for the time.
I think this title could benefit from something similar. It's a fine line to walk though, they have to be different enough to not just be a rehash.
In the demo, you could never fully "pause" the game. Even when you stopped moving, everything still moved, just very slowly.
The game most definitely turned into a puzzle in the same way that Braid's levels were puzzles. I can't see how you could say it was anything else.
IMO, the demo was a blast. If they made 30 more levels like the demo, I'd buy it. Adding grenades, swords, and interesting level designs is more than enough to warrant a purchase.
I think I can see the intent behind requiring comments be endorsed by ‘users with over 1000’ karma: this is a somewhat arbitrary way of saying ‘users who themselves are good contributors to the community’, but I think that specific way of measuring is naïve.
Using an incrementing value to represent karma means that you can slowly accrue and work your way towards achieving that state of being a good community contributor in principle, whilst in fact still behaving in all the negative ways you are hoping to minimise.
There are quite a few metrics that could be of relevance when looking at people who comment on HN. How often do they reply? Do they post the first comment, or only replies? Do they only reply to controversial subjects? Do they upvote often?
I'd propose that the solution be more subtle. As others have pointed out, you shouldn't implement a system that acts as a positive feedback loop for the most popular topics; that will simply filter out things that aren't in the zeitgeist (and god knows HN doesn't need any more of that).
My suggestion would instead be that all comments are visible immediately, but will be automatically hidden after a period of time, unless they become sufficiently popular. The length of time before they become hidden will depend on the another value, associated with the poster, which would be something akin to the ELO rating system; all users start with the same score, and then that score is modified based on how many people approve of / disapprove of their comments.
Obviously just using these things ignores context, so I'd encourage some more clever introspection of the other things I mentioned above to determine whether they're just posting on a controversial subject (maybe the first reply gets a bonus to the length of time it's visible, or controversial subjects — measured by the frequency of up vs downvotes — don't reduce your personal ELO rating as much).
Of course, these ideas could be equally terrible but I think thought should be given to testing them before committing, and using something more subtle than just slamming the door in the face of people who aren't able to get their comments into the eye line of the HN elite.
> what I determined is that there's a new definition of what "semantic" means in front-end architecture. Semantic doesn't just describe the content anymore, it describes the function as well. So using classes like "module-box" or whatever is perfectly fine.
Semantics describes a thing, but classes like ‘module-box’ don't convey any meaning beyond presentation. If you think that ‘module-box’ is semantic, then I have a whole bunch of classnames based on colours to sell you…
> the "separation of concerns" was a good principle to use when the web was a bunch of documents meant to provide content. It isn't that way anymore.
The virtues of this approach have very little to do with the web; it's a concept that pre-dates it, so it's hard to justify it having been invalidated simply by advances in web technology. Besides, a web ‘application’ is equally composed of semantic components just as much as a document is; part of the reason HTML5 came about was to reflect the kind of elements used in modern web pages.
> Using selectors like that (aside from being slow performing) completely tie the markup to the presentation. Hell, if all you did was update the list to an ordered list instead of an unordered one you'd have to update the CSS as well.
This suggests that your workflow starts with CSS and you then build markup to fit it, which his sounds completely backwards to how I approach things. You don't tie your markup to how it is presented: you declare how you want to present the markup your app is built upon. Also, if you change the markup to something with a completely different meaning (an ordered list is meant to have a different purpose than an unordered one) then of course it follows that you'd have to update the CSS, although there's no reason why those changes need be onerous or difficult.
> If you're concerned about the discoverability of the code to a new developer, DOCUMENT IT. Create a UI style guide that implements all of the major UI components and have the developer reference the style guide.
A style guide is a fine starting point regardless of how you want to approach your CSS, but documentation isn't the only way to aid discoverability of code. Selectors that communicate context and purpose can be very helpful for this too.
> I would have preferred you used the 90% of your words to give better examples of how to do things better than overstating how OOCSS and BEM are wrong
This is definitely something I'd like to do as well, but I wanted to focus on the areas I found problematic first and foremost. I may post a follow-up based on the feedback I've received.
> Why not have the presentation be the specification, and we can just build the html to conform to the that specification instead
As I said, I don't believe this is an appropriate approach for a medium which has no absolute, definitive interpretation. A website isn't how it looks, because how it looks will differ depending on how you access it. The only absolute truth when talking about websites is the semantic purpose of the markup underlying it, because purpose is universal: a navigation element is a navigation element regardless of whether it's being displayed on a TV, a desktop browser, a smartphone, or being read out by a screen reader.
> I imagine that's just because you'd rather see better looking html than you would see better looking css.
I'm actually interested in both :)
> You have the semantic issues well thought out, however you are flat out declaring data semantics are more important than presentation semantics.
What are ‘presentation semantics’? I think this is a corruption of the concept of semantics. Semantics are what a thing is, or means, or does; not how it is presented
> My CTO and designer (2 people I have a lot of respect for) were the people who eventually changed my mind on this. They said, "I don't know why this button is blue, but it's supposed to be green". Well it turns out it's blue because it has the class blue on it. Instead of trying to figure out what selector was causing this button to be blue, all I had to do was remove the blue class and add the green class. It took 15 seconds.
Changing how you structure the CSS in your application based on the whims of people whose area of expertise isn't CSS sounds like a nightmare scenario to me. If you're bootstrapping with a small team I can understand wanting to have everyone being able to contribute, but you should also be able to recognise what the limitations of their skills are. In the example you give, I would be using my web developer tools / inspector etc. to find out the origin of the erroneous property. If you're using a preprocessor there are source maps that can help with identifying how a rule was built. I certainly wouldn't conclude it's easier to use a presentational class name just so that my CTO could understand the code.
> What are ‘presentation semantics’? I think this is a corruption of the concept of semantics. Semantics are what a thing is, or means, or does; not how it is presented
Semantics just means to give something meaning. Presentation semantics (http://en.wikipedia.org/wiki/Presentation_semantics) are just marking up the data to declare your intent for how you would like it to be presented.
> As I said, I don't believe this is an appropriate approach for a medium which has no absolute, definitive interpretation. A website isn't how it looks, because how it looks will differ depending on how you access it. The only absolute truth when talking about websites is the semantic purpose of the markup underlying it, because purpose is universal: a navigation element is a navigation element regardless of whether it's being displayed on a TV, a desktop browser, a smartphone, or being read out by a screen reader.
A HTML document is just text. Technically adding links, particularly navigation, is just presentation markup. As you said, it's up to the interpreter to make sense of that markup. The basis of your argument is that presentational markup is bad though, so I'm left unconvinced here.
> Changing how you structure the CSS in your application based on the whims of people whose area of expertise isn't CSS sounds like a nightmare scenario to me. If you're bootstrapping with a small team I can understand wanting to have everyone being able to contribute, but you should also be able to recognise what the limitations of their skills are. In the example you give, I would be using my web developer tools / inspector etc. to find out the origin of the erroneous property. If you're using a preprocessor there are source maps that can help with identifying how a rule was built. I certainly wouldn't conclude it's easier to use a presentational class name just so that my CTO could understand the code.
I'm concluding that presentational class names are easier to fix for the regular small changes that come down the pipe in our project. Even if you're regularly making big presentational changes to your entire site, then you'd need something a little more abstract, like using a class to declare an element as a button instead of the direct color it should be, but like I'm said, the argument against presentation markup is still unconvincing in the face of simple maintenance.
"A HTML document is just text. Technically adding links, particularly navigation, is just presentation markup."
HTML is HyperText markup language. Hypertext is about links and references to other documents. Links are a first class citizen of a hypertext document. That's about function, not presentation.
If your CSS ‘impossibly simple’ then it sounds like you don't need it. Every tool has its place: writing HTML by hand is still worthwhile in certain situations. My article assumes you are writing CSS in a project of sufficiently large scale that how you approach architecting it is important enough to think about.
There are very few large scale projects that warrant it. Preprocessors save you a few search and replaces, little else. You're left with a stylesheet that is no longer recognizable to its author and can't be debugged via your browser's developer tools.
