romain_dardour

Tried a lot of different approaches, from markdown to notion, to native browser bookmarks. Ended up liking https://anybox.app/ - great cataloging / sorting capabilities and plenty of keyboard control

I don’t have any vested interest in this company - no hidden connection. Just happened to find a nice solution in it.

You Want everpix. They got shutdown but no product is coming close to what they had. Except maybe picturelife but they bloat their app with editing and social features unfortunately.

It we never reinvented the wheel it would still be made of stone.

Interested to hear the Hacker community's take on this.

We've been forecasting this for 2 years and agree with Nate Elliott : "As a result, marketers hoping to interact with consumers online might be better off investing in social features that exist on their own websites, or in smaller, more niche social networks, Mr. Elliott said."

That's why we built Hull in the first place.

Now this subject is this 15min's subject. What does the Hacker community think of this specific idea?

Or you could use http://hull.io and not even need backend code

This article is several years old. Its concepts have been implemented in http://aurajs.com with the author as the project lead.

Js gained wide adoption thanks to favorable comparison on specific traits when compared to other languages.

- ubiquity - lower barrier to entry as far is toolchain setup is concerned. Nothing to install to build a Hello world. - no weird concepts to grasp at first: many commonalities with other languages, meaning you don't start the learning curve with a big step.

I could go on but the gist is that JS is kind of like the pop music of programming languages: easy to like, with room to grow (as opposed to Justin Bieber or Miles Davis who miss one of these traits.)

To the question of what will be the next "buzz" (Js is a buzz, but those have different timelines and emotional loads than "leave Britney alone") the answer is:

Something even easier to grasp and access with a barrier to entry, smoother learning curve and wider applications.

It might even be an abstraction like those of Brett Victor.

I'd say that's not so much the language but what it allows beginners to achieve that is wave-defining.

Development has become mainstream and JS is the Pop Music of our days.

This is GM

Newlines are supported on twitter in 3rd party apps, but not in the twitter card nor twitter app indeed.

Also, the blog is not called "Apple Sloppy UIs", but "Sloppy UIs". That still qualifies.

To clarify things, we just posted this on the web site:

We love Apple. We think this is the best way to point out what's not up to their standards so they can fix it. It's all about intellectual honesty, not trolling.

My point exactly. We love all things Apple, and I want to see those fixed.

two t's are better than one :)

Poster here: Indeed it's just me submitting. But it's open to submissions.

I'm not answering every single case you mention. The examples I posted show how inconsistent the UI is.

Taste is in the eye of the beholder and I didn't mention what I find ugly but what shows a lack of afterthought.

Just one example here to answer, "Poor Contrast" (http://sloppyui.tumblr.com/image/61439835569) On an iOS device, this is not "Subtle" but unreadable.

With a minimal amount of work, dsowers could implement support for hull.io and implement comments exactly as he'd want to - disclaimer: I work there.

Find a company you'd want to work in, contact them. If you don't find one, build it.

You're passionate enough to have written this. Most people do not. Don't let this situation destroy it.

My co-founder lived in that kind of company for 2 years. He learned a lot of what not to do but it took its toll.

Sidenote. We're looking for passionate people.

Having a professional logo gives it a more polished first contact. For a tool that makes disparate bits easier to use it's part of the contract. Who cares how it's made when it brings convenience to the table?

You should take a look at aura.js (http://github.com/aurajs/aura). Abstracts many of the steps of this article (require.js, bower...) and offers a decoupled architecture for scalable and well structured apps. There's also a yeoman generator, and they have an extensions system that seamlessly integrate handlebars.js for example.

Actually you can combine middleman and dynamic pages to get fast static pages and still keep a few dynamic endpoints. We did this on our website http://hull.io for email registration, and blogged about it here : http://blog.hull.io/post/45912703356/the-perfect-almost-stat... - when 90% of your users only consume static content, you greatly benefit from this.

http://hull.io - social platform as a service

I don't believe it's gonna roll that way with developers. They want full control and access to their data and Facebook is not the kind.

Making end users pay is a huge barrier to entry for startups. Not all can afford it. And App.net is there to play zookeeper, and could shut them down if they do anything out of bounds. For users this is great but for startups it's hugely dangerous. So app.net has a marketplace problem : to overcome this they need to be huge (think Apple App Store huge) and to be App Store huge they need the startups and users.

Disclaimer : We build hull.io. we think that developers need stay in control of the data and responsible for themselves for this to work.

We're really sorry about this. We're taking heavy traffic, and our Redis instance is getting hammered, which is why certain inits are breaking.

Actually, all those trackers are an oversight from me.

We have tracking both from the app (it handles it's own traffic), and the website.

You're totally right we don't need all of those. We'll remove those from the website on this page.

While I agree about the "no reinventing the wheel" part (after all that's one of the benefits of our product), I think Cappucino had made some choices that the random developer could not come to terms with.

I don't think that this is due to laziness or rouded-corner cravings (although the "new shiny toy" effect is very much existing).

I think this has more to do with the different timelines web developers face when building apps. Not all of them can afford the long learning curves required by Cappucino and the fact that objective-J is only useful for Cappuccino. Not all of them need to build app-looking apps or spend lots of time bending the defaults to look like something else

So the web community turns to low learning curve libraries as a side effect of not having the time to commit (as opposed to not wanting), better ones coming out all the time (things moving at a whole order of magnitude faster than in other software development areas), and using only 10% of the power brought by cappuccino.

This encourages more quick, single feature libs, which in turns brings more developers into that worldview.

Note that this argument is not about wether this is right or wrong. More about the why.

One can note that making those micro libraries work together is getting harder and harder, and that some folks (full disclaimer, we are one of those) are building glue layers and light architectures to guide developers and ease integration and make those libraries interact together seamlessly.

Take http://github.com/aurajs/aura (that's the one we're working on). It acknowledges both the fact that small, single-feature libraries are the way the web is heading, and that making those interoperable, and easy to load (a clean module system is central to aura) needs work.

Maybe small, badly written, non interoperable, single use libraries are just a step on the way to a truly modular, flexible and light web development process.

The 99% aren't customers. They're the product.

You're trying to sell people an Idea, this is a survey.

Getting people to pay for stuff is not the same as asking them if they would.

People don't buy Ideas, they buy Value.

Hull is not a point-and-click social network creator. It's a developer platform.

And who says the networks those will build will be niche ;) ?

CMS are mainly document-centric, whereas Hull is interaction-centric.

The social mechanics are available for those CMS as plugins, yes, but you need to work out how to integrate them, when they're made by different developers, and write glue code.

A big strengh of hull is also it's client-side widgets library, that just work and allow you to combine and extend them easily.

Lastly, hanging off OpenGraph does not make you the owner of the data.

Use cases and hands-on demos are coming really soon.

What can be built on top of it is up to your imagination.

Thanks Anuj, it's been our vision from the start. The demo is along these lines, and is coming soon.

Thanks for the notice too.

Noted. thanks :)