JS Developer & Chrome Application v2 Mockups

[Kaspar Emanuel]

Hi all,

I am applying to be your "JS Developer" and have been in touch with Mathieu (email copied below) and have started to hang out on the #mooltipass IRC on freenode. After some further discussion and a good look at this document it seems I am really well suited for this work as I have experience in the whole stack from hardware to firmware to JS to graphics.

I am going to make a formal quotation and offer a fixed price for this contract once I _fully_ understand the requirements (I am getting there) and can make some estimates of time-spent for myself. To aide with this I thought I would start of by putting together some mock-ups of the direction I would like to take the application in, in terms of look and feel.

Mathieu was very adamant that we be as transparent and democratic as possible with this whole process and if we can learn anything from western democratic systems at all, it is that we need two candidates that are almost the same ;). So without further ado:

• Candidate 1: "The menu button candidate"

• Candidate 2: "The hardware menu copy-cat candidate"

For either one I would suggest also making a tray-icon out of the attached graphic (icon_original.png) and then allowing the application to be minimized to tray by default.

There are pros and cons of course and currently I am leaning towards candidate 1 as the menu would be more flexible (say if we decide to have more than 4 options) and less confusing (can I use the mooltipass to control this menu?). I am also not super clear on the distinction between "manage" and "settings" but I like the tiny icons I came up with for candidate 2 and would use these in the candidate 1 menu.

So let me know your thoughts in general or any nit-picks or questions via this group or IRC.

Cheers,

Kaspar

---------- Forwarded message ----------
From: Kaspar Emanuel <kas...@monostable.co.uk>
Date: 14 December 2014 at 12:27
Subject: Mooltipass Javascript Developer
To: limpkin@...fr

Hi Mathieu,

congratulations on a successful campaign!

I think we have interacted once or twice on Reddit (/u/kasbah). I remember asking you some details on the production of your Whistled.

I contributed towards the Mooltipass too and saw on your latest update that you are still looking for a Javascript developer.

I am an electronic design engineer and firmware developer but I got started programming as a teenager with Javascript and PHP (gasp!). These days I mainly get hired to write C and design PCBs but I have been doing a lot of my work own my own lately that got me back in to developing in Javascript: my 1clickBOM extension. (It’s actually in Coffeescript but the Coffeescript language was designed with the moto “It’s just JavaScript” — it’s just a more terse way of writing Javascript with some nice Pythonesque syntactic sugar).

I started scoping out your requirements a bit and found your google doc but I am guessing those points noted under “Extension” there are not the end of the story. I also found the archive/chrome.ext on your Github but I was wondering if there is anything more up-to-date that I should be looking at.

I also have a few connections with Javascript developers and Graphic designers. For example I know the graphic UI designer I used to work with on this is a project still freelances so I can farm out work if that helps.

Anyway, please get back in touch if you think you could use my help on this and we can flesh out the requirements, schedule and budget.

All the best,

Kaspar

​

[Bjorn Wielens]

Hi Kaspar!

While I like option 2 for the unity with the mooltipass interface (well, I _am_ partial to my design ;-) ) I completely agree that it could get confusing for people and trying to interact with it - for that reason option 1 is probably best unless we can find a creative way to make it clear it isn't associated with the interface on the MP.

Of course I'm happy to provide SVGs of the original artwork that is used on the device UI itself for you to incorporate into the software as necessary, and I should be able to find some time to make a few additional icons in the same style if necessary.

As a technicality, you'll probably want to refrain from using the Hack-a-day logo for the 'developer' menu entry, it's trademarked and it was decided a while back to do away with using that logo on the device to avoid licensing encumbrances.

I wish you all the best and look forward to seeing what you can do!

Regards,

Bjorn.

--
You received this message because you are subscribed to the Google Groups "mooltipass" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mooltipass+...@googlegroups.com.
To post to this group, send email to moolt...@googlegroups.com.
Visit this group at http://groups.google.com/group/mooltipass.
For more options, visit https://groups.google.com/d/optout.

[David Ehnebuske]

Hi Kaspar,

I agree with you that candidate 1 is the better choice, for both the reasons you cite. It has plenty of graphical unity with the MP hardware interface without the confusion of looking like it might be a different way of doing the exact same thing. And it has the flexibility needed at this point in the development.

Nice work.

Dave Ehnebuske

[Kaspar Emanuel]

Hi Bjorn,

While I like option 2 for the unity with the mooltipass interface (well, I _am_ partial to my design ;-) ) I completely agree that it could get confusing for people and trying to interact with it - for that reason option 1 is probably best unless we can find a creative way to make it clear it isn't associated with the interface on the MP.

I too am a fan of your designs and this one is merely a tribute ;). The only way option 2 would not be confusing I think is if you could _actually_ use the MP to control it but that is likely too much re-work on the firmware side.

Of course I'm happy to provide SVGs of the original artwork that is used on the device UI itself for you to incorporate into the software as necessary, and I should be able to find some time to make a few additional icons in the same style if necessary.

Yes, this would be excellent!

 

As a technicality, you'll probably want to refrain from using the Hack-a-day logo for the 'developer' menu entry, it's trademarked and it was decided a while back to do away with using that logo on the device to avoid licensing encumbrances.

Aww.. but it fits so well in this instance! Developed on Hackaday etc. they will not make an exception? I did read that thread a bit but I guess I missed the conclusion.

Cheers,

Kaspar

[Warren Besore]

I agree with you. Candidate 1 is the better choice.

--

[mathieu...@gmail.com]

(very busy writing code)

+1

[Kaspar Emanuel]

Would there be any objections to using elm-lang.org for the UI?

I have been writing a lot of Elm and Haskell and I think it could speed up my development time as well as make for cleaner more maintainable code.

On the other hand it isn't just Javascript and it would mean any other developer would have to learn Elm to make changes to the App. The docs for Elm are very good though and it is a lot of fun to learn.

[mathieu...@gmail.com]

I see more positive points than negative ones.... but this is the kind of decision that should involve the wise guys in this mailing list

What do you think?

[David Ehnebuske]

As a techie, I'm always up for a new approach, and I like the
fundamental ideas behind Elm. A lot. I'm impressed that Evan Czaplicki
has ben very dedicated to developing the language and tools for it for a
couple of years now. And github shows that in addition to Evan, Elm has
some clever friends who help out. And, of course, that it's all open
source is lovely.

That said, I get a little anxious when I put on my business person hat.
From a business perspective, committing to Elm is a big deal for MP. The
MP project would be making a pretty big bet that Elm will continue to
gain traction so that people who would like contribute to MP will find
it worth while to invest in learning the language and tools to do so.
The project would be betting that Evan and company won't lose interest
in Elm or run out of the energy they need to keep it vibrant and alive.

In short, it seems to me that adopting Elm means betting that the
substantial risks associated with a big dependency on Elm would be more
than repaid by the even more substantial development advantages of the
Elm language and tools. I simply don't know whether that's true or not.
I do know it's a really important decision -- one I wouldn't make
lightly, especially now that MP is playing with a lot of people's money.

Hope this is useful to making the decision.

Dave Ehnebuske

[Kaspar Emanuel]

That is indeed very useful input David, thank you very much.

I have a few points:

1) I have clarify that I am proposing a combination Elm and Javascript (and re-using as much of the existing code as possible). Elm here actually replaces only some front-end JS, the JQuery library and all HTML and CSS documents. With a nicely decoupled design I could envision a scenario where all the Elm code could fairly easily be replaced by something else without affecting the back-end communication.

2) The existing code uses JQuery which, while it does have a much more wide adoption, does have some of the same risks associated with it as well.

3) As you say, Elm seems to have a healthy developer community and it does have the financial backing of Prezi who support several developers who work on it.

4) Another thing to bear in mind is, as I will explain in more details in a subsequent thread (that I am currently drafting), I am offering a fixed fee for this work so I will, at least, bear the financial risk of any additional time spent due to this decision.

Having said all that, while I would prefer Elm, I am comfortable with writing pure Javascript or JQuery and of course CSS & HTML.

​

[Miguel Angel Borrego]

Hello Kaspar,

As David said, my opinion is that despite ELM will speed up the development process, it will create a barrier in the project to have more contributions from other people. 

You said it will be used only to create the user interface, so... how easy it will be to other person (who doesn't know anything about ELM) to get into your code ?

Could you describe the difference in development time of doing the user interface in JavaScript vs ELM ?

Best Regards,

Miguel

[Kaspar Emanuel]

Hi Miguel,

You said it will be used only to create the user interface, so… how easy it will be to other person (who doesn’t know anything about ELM) to get into your code ?

I think the biggest barrier here is an up-front “what the hell is this” barrier as Elm looks very different from JS/CSS/HTML. Elm is a strongly typed purely functional language which means everything is a function and takes something of a fixed type as it’s input and something of fixed type as it’s output.

The approach is very declarative and there is no mutable data (incl. no state). This makes it much less likely that you go “what the hell is this” once you get over that initial hump. It enforces a discipline that guides the design which would be harder to practice in JS.

Could you describe the difference in development time of doing the user interface in JavaScript vs ELM ?

This is of course very hard to quantify. One of the biggest factors here is probably just that I enjoy programming in Elm much more so I am very likely to spend my own free time writing Elm.

But to illustrate the difference a little: one of my first programs in Elm was (loosely) re-writing this JS tutorial. What I came up with was an un-moving version of this and it took an additional 2 lines and one line change to make the whole thing move with the mouse as it does. I am sure it would take a  a lot more to make the pure JS/CSS/HTML version move with the mouse like that.

You can easily compare the two styles as well. The JS version is very imperative (now we do this, then we do that) and the Elm version is more declarative (this is a branch, to draw a branch we take a branch and return an element).

Ciao,

Kaspar

​

[Warren Besore]

Kaspar,

 

From your explanations, it sounds as though ELM is, in essence, playing the role that would be filled by a js framework such as jquery, so the net result is trading one form of complexity for another. I say go for it. Declarative programming seems to be the direction where things are headed.

--