generateui's comments

Those icons are absolutely horrible. They are images, distracting the viewer by the amount of details. Icons should convey only the bare minimum of shape. The metaphor of the meaning should be captured, not the incredilous picture of a remotely possible parrallell.

A typographer, talking about screen density, and clarity on his blog using a serif font. Oh, the irony.

I placed the 2010 Dutch Pirate Party (Piratenpartij) election program on Github. I try to elad by example: Set the example by the "internet party", then hopefully others copy & paste it.

https://github.com/generateui/VerkiezingsProgrammaPiratenPar...

Your consuming code is tied to Foo. In dart, the consuming code only needs tying up to the interface.

> You always need a class

Nope. That's the whole point which I am trying to communicate: you do not need a reference to a class to get the instance of the interface from, as you confirm later on:

> As to the calling code needing to know about that one concrete implementation:

My personal feeling of liberation comes from the fact that the code is simpler and more clear. The non-coupling is nice, but can be achieved with dependency injection too: the point is the transfer of characters into a mental model which is more efficient with the named constructors/factory constructors.

> A factory method is a classmethod, not an instancemethod.

This completely depends on your implementation. It's possible to implement it as instance method, or static method.

> Uh no it does not, it just needs a class.

Whether it be a static factory method or an instance method, fact is you need a reference to an implementation (class). In dart, you can do

  List someListInstance = new List();

where List is an interface. There is none class needed in your consuming code, none. In C# or Java, this is impossible: You need _some_ class (whether it be a static method on it, or an instance method) to get a new instance of the interface.

Named constructors felt very liberating when working with Dart.

  new List.from([instance1, instance1]);

delivers a lot of clarity, while offering the promised decoupling by the GoF:

> Define an interface for creating an object, but let the classes which implement the interface decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses.

There does not need to be any knowledge of _any_ class. A factory method _still_ needs a class instance, you don't need them with factory constructors.

A classical, say Java or C# way will still need coupling to such a class. In dart, there is real decoupling going on.

I am very curious to the business model Diaspora will pursue. any details about that already?

After it became apparent by parlement representitives they probably had to pay "chatheffing" - chattax, this law was reality quite fast.

It's pretty hopefull the law passed senate unanimously.

If the producer would share the design of the iron with the world, the risk would be reduced significantly. The leftover parts could be identified by crowdsourced databases as nonimportant, or as risky to leave out.

Can you define "support"?

Well said. Also, we engineers let lawyers eat our lunch. Law is there for a reason, but we should dominate law, and not let law dominate us.

This is potentially very destructive to Silicon Valley.

That's where inifinite scroll is a good idea. Infinite scroll is usually correctly applied to datasets where it is unknown how many items the dataset consists of. E.g. google images, tweets, et cetera.

We already have what you want, it's called a scrollbar ;).

And software engineering is quite dissimilar, if not completely different to computer science. Creating API's, building user interfaces, testing, has little to do with computer science, or information theory, or mathematics. Yes, it has some overlap, but not nearly as much as academics like to think.

Take an example as implementing a 3D renderer. A computer scientist might argue that underlaying 3D calculations should be correct. A software engineer might optimize for speed, and simply allow incorrect/imprecise calculations, as long as the rendered result does not look very different.

What's the deal about the infinte scroll? Everytime I have to use it, it feels very unpleasant. The problem is the scrollbar which suddenly does not accurately hint the position of the document I'm in.

A solution might be to change the scrollbar hinting from absolute to relative. A simple ∞ added below the "scroll down button" on the scrollbar might just fix this.

Google,

Please add a warning that when a serif font < 24px is used for the main text, readability is degraded on most screens (new iPad being a notable exception).

Sincerely,

The internet.

I had that experience a few years ago, when javascript execution engines where not optimized yet for speed. Today, I have the same experience with apps built using flash, where there is an annoying delay when hovering/clicking. A mature webapp running on a fast javascript engine does not give me any noticable delay. The "feel" is just the same as a native app.

Another difference is UI startup time. The Java VM took minutes on most computers to go from URI entry to first UI display. Compare that to optimistic rendering all browsers do today, where delay is mostly dependant on network speed.

I have been using webapps for said tasks more and more. Many tasks performed using a webapp do not yet have compelling advantages. But soon they will get them, I think. To name a bold example, http://C9.io: Not yet bringing many compelling advantages, but the tipping point is close.

pǝǝɹƃɐ