A small baby cannot put its pacifier into its mouth by itself.  But it manages to insert a piece of cloth .

Why not make a pacifier that, for the baby, is as easy to insert as a cloth?

I recently changed floor and had to remove baseboards/moulds.  These were easy to break/crack which would later lead to more work piecing them together to make the crack invisible.  Not to mention all the dents I made when making the first try to pry them loose.

If they had been screwed this wouldn’t have happened.

In another room I had to paint the moulds.  The result was sometimes not satisfactory.  If I had been able to screw them loose it would have been better.

What about screw holes? one might ask.  Are there supposed to be big black holes or heads sticking out?  That can be solved I say.  I don’t know yet but there are plugs, screws without head but threads with different rise or another solution.

There already exists moulds that are fastened on fasteners that are attached to the wall.  The implementations I have seen so far are slightly ugly, doesn’t always make a nice fit and can’t be used for pressing the floor down, which is needed sometimes.  A good idea though.

If the moulds are detachable they could also be milled on the backside to allow for electrical wires.

Finally I don’t want to stop the screwing idea at mouldings and baseboards.  Use it for everything where there is a nail.  It makes redecorating easier.  And screwing isn’t harder than nailing in the first place.

The keyboard layout is created for touch typists (there are some comments about this but bear with me) but most people don’t touch type.

So why not have a keyboard that is better for index finger typers?  The space bar isn’t pressed by the thumb so it could be smaller and give place for other buttons.  Ditto almost all buttons since an index finger typer probably looks at the keyboard too.  One could also get rid of the qwerty layout which isn’t very good for typing and it makes finding keys harder for someone who seldom types.

Personally I am using ergonomical keyboards (yes – I touch type) since they are easier on the wrists; but I am on the lookout for customizable keyboards where I can bend it and place the keys wherever I like.

If you dear reader is programming and using a Swedish keyboard let me present 1337 keyboard layout for you.  It has a US base (better for programming) but with åäö (necessary to write Swedish) on it too.  Then I have switched the figures and the special characters on the top row so there is no need for pressing shift every time you want a parenthesis.

There are many ebook readers, several for every device.  But no one can synchronise my reading between the devices.  (i.e. none that I know of)

What I want is to read my book in bed on ebook reader hardware.  Then, while commuting, I pick up my phone and continue reading where I left off.  Back in my sofa at home I read on my tablet or TV.  Not to mention to be able to read at the computer.

I suggest skipping creating an app for every device but instead make it online.  I mean… what can’t be solved by HTML5 nowadays?

There is a solution, Ibisreader, which already today keeps some of my ebooks.  I can read my book at every web browser be it computer or phone.

What it lacks though is a better user interface and above all a better way to track where I am in the book.  It uses some kind of chapters? and they can span several screen heights.  I would like to have the browser know which page, screen wise – not paper page wise, I am on so it can open the right page when I continue reading on the next device.
There won’t be an exact match when moving from a bigger screen to a smaller, say a tablet to a phone, but unless I have a very big tablet with a very small font it won’t be far off; and probably not even then.

Ibisreader is F/OSS so I guess it would be a good place to start.  It could also be a nice way to learn Html5.

It would be useful with a client side logging solution written entirely in javascript.  With Html5 comes a client side database.  Already today we have cookies that could be used.

Logging could be done  in a round robin fashion where old logs are dropped so one always keeps the latest x logs in the database/cookie.  One could also send thelog back to the server if needed.

That way we wouldn’t need alert calls.  Especially forgotten alert calls that goes into production.

Think SMS and Twitter – simplicity on the verge of stupidity.

There are so many needs for just 1 page.  Be it a restaurant menu or a party specticulaire.  Create a simple site for creating very very simple pages.  Limit each project to 1 page.  Limit to already created templates.

In the simplest case one uses a URL like www.example.com/id=12.  It would be nicer though to have projectname.example.com.  One could buy a bunch of URLs and let the user choose from them.  myproject.otherexample.com or sunday-evening.has-the-menu.com.

Let advanced users upload PDFs or DOCs or ODFs and convert it.

One could, for the advanced advanced users, make it possible to upload HTML and CSS.

Just keep it stupidly simple, otherwise we will try to recreate the home pages of last century.

Anyone who has cleaned a room with wall mounted radiators knows the problem.  There is no way to properly clean the wrinkled surfaces.

Anyone who has painted a room with wall mounted radiators knows the problem.  There is no way to paint the wall behind the radiator without applying some on the radiator too.

On the radiators I am used to, it is possible to unfasten and tilt them slighty outwards; which might lead to a leakage in the radiator/tube joint since they are not constructed for movement.  Doable for painting, which is only done once every 20 years, but not applicable for cleaning.

Why not have soft tubes so the radiator can easily be detached?  I have such on my washing machine and dishwasher so the technique and material already exist.  There is no need to have soft tubes all the way, just lead the hard piping to behind the radiator and soft tubing from there.

As I have percieved (all) logging frameworks today work in a synchronous manner.  This means that logging comes with a performance impact.

One could create a logging client that sends its entries to a queue.  This queue is then fetched by another process.  The total processing power required is greater than a synchronous solution and issues might arise when time is a factor.  But for the other cases I believe this could be handy.
And one could build a switch into the framework that forces synchronous logging for the times it is necessary.

Then create a log viewer client with more intelligence than just listing text entries.  I plan to write about this, but don’t hold your breath.

—-

To start with I am thinking of a message queue.  Let the client write to the queue.  Then have another process read the queue, possibly from another machine.  Let the logging entries be identifiable by a guid.  Let the reading process be able to sort these guids to their respective category and present it in a readable way.

Get a spare monitor like a phone or usb and let a program continously show your log with a cool graph.  Add sound and a force feedback joystick and it will be more fun than a barrel load of monkeys.  All without drawing power from the production machine.