Summary: When designing a user interface, think about the user, and what they want to know. Don't just present the information you know.
As part of my job I've ended up writing a fair amount of user interface code, and feedback from users has given me an appreciation of some common mistakes. Many user interfaces are designed to present information, and one of the key rules is to think about what the user wants to see, not just showing the information you have easily to hand. I was reminded of this rule when I was expecting a parcel. On the morning of Saturday 10/1/2015 I used a track my parcel interface to find:
The interface presents a lot of information, but most of it is interesting to the delivery company, not to me. I have basically one question: when will my parcel arrive. From the interface I can see:
- The parcel is being shipped with "Express AM" delivery. No link to what that means. Searching leads me to a page saying that guarantees delivery before 1pm on a business day (some places said noon, some said 1pm). That is useful information if I want to enter into a contract with the delivery service, but not when I'm waiting for a parcel. What happens on Saturday? Do they still deliver, just not guarantee the time? Do they wait until the next business day? Do they do either, as they see fit?
- My parcel has been loaded onto a vehicle. Has the vehicle has left the depot, or is that a separate step? How many further steps are there between loading and delivery? This question is easy to answer after the parcel has been delivered, since the additional steps show up in the list, but difficult to answer before.
On Saturday morning my best guess about when the parcel would arrive was between then and Monday 1pm. Having been through the complete process, I now know the best answer was between some still unknown time on Monday morning and Monday 1pm. With that information, I'd have taken my son to the park rather than keeping him cooped up indoors.
I suggest the company augment their user interface with the line "Your parcel will be delivered on Monday, between 9am and 1pm". It's information they could have computed easily, and answers my question.
The eagle-eyed may notice that there is a plus to expand to show more information. Alas, all that shows is:
I think they're trying to say my puny iPhone can't cope with the bold font that is essential to tell me the status and I should get an iPhone plus... Checking the desktop website also showed no further information.
I need basic calculation (on prices and quantity), and for some reasons I don't like float or double (mainly rounding errors), so I'm thinking of using Ratio (or Decimal ?) instead. Is it something widely used or at the contrary that I should avoid (and if so, why ?)submitted by maxigit
[link] [18 comments]
Can someone please tell me why Haskell can't be used in embedded systems? I mean I know it can be used on the ARM platform. What I'm really asking is why can it not be used in places where C is used? Like Linux device drivers for example? While golang and rust are talked about as potential heirs to C.... How come Haskell is not? After all Haskell compiles to object code as well..submitted by desijays
[link] [23 comments]
FP Complete's mission is easily expressed: increase the commercial adoption of Haskell. We firmly believe that- in many domains- Haskell is the best way to write high quality, robust, performant code in a productive (read: fast-to-market) way. Those of you who, like me, are members of the Haskell community are probably using Haskell because you believe the same thing, and believe- like us- that we can make the world a better place by getting more software to be written in Haskell.
By the way: FP Complete is looking to expand its team of Haskell developers. If this idea excites you, don't forget to send us your resumes!
There are two interesting groups that I've spelled out in that paragraph: commercial users of Haskell, and the Haskell community. I want to clarify how our software development process interacts with these two groups, in part to more fully answer a question from Reddit.
The Haskell community has created, and continues to create, amazing software. As a company, our main objective is to help other companies find this software, understand its value, and knock down any hurdles to adoption that they may have. These hurdles include:
- Lack of expertise in Haskell at the company
- Limitations in the ecosystem, such as missing libraries for a particular domain
- Providing commercial support, such as high-availability hosted solutions and on-call engineers to provide answers and fix problems
- Provide tooling as needed by commercial users
You can already see quite a bit of what we've done, for example:
- Create FP Haskell Center, which addressed requests from companies to provide a low-barrier-to-entry Haskell development environment for non-Haskell experts
- Put together School of Haskell to enable interactive documentation to help both new Haskellers, and those looking to improve their skills
- Start the LTS Haskell project as a commercial-grade Haskell package set, based on our previous work with FP Haskell Center libraries and Stackage
- Provide Stackage Server as a high-availability means of hosting package sets, both official (like Stackage) and unofficial (like experimental package releases)
There's something all of these have in common, which demonstrates what our software pipeline looks like:
- We start off gathering requirements from companies- both those that are and are not our customers- to understand needs
- We create a product in a closed-source environment
- Iterate with our customers on the new product to make sure it addresses all of their needs
- After the product reaches a certain point of stability (a very subjective call), we decide to release it to the community, which involves:
- Polishing it
- Discussing with relevant members/leaders in the community
- Making it officially available
Not every product we work on goes through all of these steps. For example, we might decide that the product is too specialized to be generally useful. That's why we sometimes hold our cards a bit close to our chest: we don't want to talk about every new idea we have, because we know some of them may be duds.
Some people may ask why we go through that fourth step I listed above. After all, taking a product from "it works well for individual companies with ongoing support from us" to "it's a generally viable product for commercial and non-commercial users" is an arduous process, and doesn't directly make us any money. The answer is simple, and I already alluded to it above: the great value in Haskell comes from the wonderful work the community does. If we're to succeed in our mission of getting Haskell to improve software development in general, we need all the help we can get.
So that's our strategy. You're going to continue seeing new products released from us as we perfect them with our customers. We want to find every way we can to help the community succeed even more. I'm also making a small tweak to our strategy today: I want to be more open with the community about this process. While not everything we do should be broadcast to the world (because, like I said, some things may be duds), I can share some of our directions earlier than I have previously.
So let me lay out some of the directions we're working on now:
- Better build tools. LTS Haskell is a huge step in that direction, providing a sane development environment. But there's still quite a bit of a manual process involved. We want to automate this even more. (And to directly answer hastor's question on Reddit: yes, we're going to release a Docker image.)
- Better code inspection. We've developed a lot of functionality as part of FP Haskell Center to inspect type signature, identifier locations, usage, etc. We want to unlock that power and make it available outside of FP Haskell Center as well.
- In a completely different direction: we're working on more powerful distributed computing capabilities. This is still early stage, so I can't say much more yet.
Outside of products themselves, we want to get other companies on board with our goal of increased Haskell adoption as well. We believe many companies using Haskell today, and even more so companies considering making the jump, have a huge amount of ideas to add to the mix. We're still ironing out the details of what that will look like, but expect to hear some more from us in the next few months about this.
And I'm giving you all a commitment: expect to see much more transparency about what we're doing. I intend to be sharing things with the community as we go along. Chris Done and Mathieu Boespflug will be part of this effort as well. If you have questions, ask. We want to do all we can to make the community thrive.
FP Complete is expanding yet again! We are looking to hire for several new engineers to join our Haskell development team, both to build great new core products and in partnership with our clients to apply Haskell at a large scale. Some of our recently announced core products include the Integrated Analysis Platform, Stackage and LTS Haskell, with much more to come. If you’d like to be part of our team and shape the future of Haskell, please send a resume or CV to firstname.lastname@example.org. Any existing work - either a running website or an open source codebase - which you can include as links be greatly appreciated as well.
We will want you to start right away. Depending on your current jurisdiction, this will either be a full-time contractor position, or an employee position. This is a telecommute position: you can work from home or wherever you choose, with little or no travel. Location in North America preferred; but you will work with colleagues who are both on North American and European hours.
- distribute existing and new code over large clusters,
- code parallelization and performance tuning,
- interface with foreign math and scientific libraries,
- relentlessly refactor for composability, testability and clarity,
- identify performance bottlenecks and debug known issues,
- implementing unit tests, integration tests, acceptance tests,
- write clear and concise documentation.
- strong experience writing process driven application code in Haskell.
- experience building reusable components/packages/libraries and demonstrated ability to write well structured and well documented code,
- ability to evolve and refactor large code bases,
- experience working under test driven methodologies,
- Ability to interact with a distributed development team, and to communicate clearly on issues, in bug reports and emails.
These further skills are a plus:
- Bachelor’s or Master’s degree in computer science or mathematics,
- experience developing products in a regulated environment (avionics/medical/finance).
- experience building scalable server/Web applications,
- (web) UI design and implementation experience,
- an understanding of the implementation of GHC’s multithreaded runtime,
- experience as an architect and/or a creator of technical specs.
I'm curious if people have any insight into the status of supercompilation in GHC. The branch built by Max Bolingbroke for his PHD thesis seems to need some work before it will work again with the current builds. Supercompilation seems to have a lot of potential and I'm wondering if people see a future for it in GHC?submitted by biglambda
[link] [10 comments]
Here are the YouTube video and slides of my Haskell Symposium 2014 talk on using Objective-C inline in Haskell programs. This provides a fairly convenient way to integrate Haskell code into the model layer of a Mac app written in Swift or Objective-C.
I got annoyed that every time I build something in a new cabal sandbox I have to wait for the same versions of lens or haskell-src-exts to compile forever.
Couldn't we just cache the build directory from which we installed a package instead of throwing it away after every build?
ghc --make has very good recompilation avoidance and flag change detection - I think we should use them. The cache does take some space in my home directory, but I accept that for the 20x faster build it allows.
This method will pick up changed dependencies (e.g. it will build correctly when the version of haskell-src-exts's dependency pretty changes between two builds) because ghc --make notices that.
Here's a proof of concept patch: https://github.com/nh2/cabal/compare/nh2:before-buildcache...buildcache
What do you think?submitted by nh2_
[link] [28 comments]
I posted this on haskell-cafe and a couple of people responded and I figured I might get some more views here ...
My hope is to eventually fill the need in the Haskell ecosystem for a native GUI library that:
- runs on all platforms
- is easily installable
- is small and fast
- has a minimum of dependencies. Currently this library uses only base, bytestring and c2hs.
- is conservative with extensions. Currently the most recent extension required is GADTs.
If any of this sounds good to you, I could use some help with:
- testing the build on Linux and OSX. This should be as simple as installing FLTK, cloning the repo and running cabal build. Better instructions are in included README.
- getting it to build on Windows. I unfortunately don't have access to a Windows machine.
- getting it to build on older GHC's. I used 7.8.3 because that is what I have, but it should work back to the first version of GHC that introduced GADTs. Unfortunately the included Setup.hs is non-trivial and I been having trouble getting it work with versions of Cabal older than 1.20 due to breaking API changes across versions.
- building a single library. Currently the C/C++ wrappers and Haskell bindings are two separate statically linked libraries. They are copied to the same location so applications built with this package don't have to know that, but it would be ideal if it was all-in-one.
- building a shared library on Mac OSX.
Any other feedback you have is totally welcome.submitted by deech
[link] [15 comments]
Previously I wrote about a simple state machine in Haskell and then offered a simple example, an adder. As I wrote in the initial post I’ve been using this to implement communication protocols. That means IO, and for that I’ve been using conduit. In this post I thought I’d show how easy it is to wrap up the adder in conduit, read input from stdin and produce the result on stdout.
At the top level is a function composing three parts:
- input from stdin
- processing in the adder
- output on stdout
This can be written as thisprocess :: ResourceT IO () process = source $= calc $$ output where source = stdinC output = stdoutC calc = concatMapC unpack =$= wrapMachine calcMachine =$= filterC f =$= mapC (pack . show) where f (CalcResult _) = True f _ = False
The input to the adder is ordinary Chars so the ByteStrings generated by stdinC need to be converted before being handed off to the state machine, which is wrapped to make it a Conduit (see below). The state machine is generating more signals that I want printed, so I filter out everything but the CalcResults. Then it’s passed to show and turned into a ByteString before sent to stdoutC.
I think the implementation of wrapMachine shows off the simplicity of conduit rather well:wrapMachine :: (Monad m) => Machine state event signal -> Conduit event m signal wrapMachine mach = do maybeEvent <- await case maybeEvent of Nothing -> return () Just event -> let (newMach, signals) = stepMachine mach event in do yield signals wrapMachine newMach
The main function is as short as this:main :: IO () main = do hSetBuffering stdin NoBuffering hSetBuffering stdout NoBuffering runResourceT process
The result is about as exciting as expected% runhaskell Calculator.hs 56 42 +CalcResult 98 17 56 +CalcResult 73
It never exits on its own so one has to use Ctrl-C to terminate. I thought I’d try to address that in the next post by adding a time-out to the adder machine.