Where User Experience fits in

[Matt Farina]

We're going to discuss technical topics quite a bit here but there's another angle we need to consider.... User Experience.

Package managers solve a problem for users. For people. The experience people have with those tools make a difference. If the masses don't like it they will be disgruntled. If they love it they will rave.

We want the masses to like this in addition to it having utility.

Useful = Usability + Utility

I have a car analogy for this. If I go to a rental car company and get a car I can get in and drive it within a minute or so. Doesn't matter the make or manufacturer. The base controls are the same. From a 1950's pickup truck to a brand new Tesla. Sure, there are differences and that's where innovation and comfort can happen. But, I can still drive them both.

While not exactly as easy, package management is pretty similar among programming languages. Package managers drive in a similar way. Once I learned one it was pretty easy to just drive the rest with just a couple minutes looking at them.

Someone coming from another language with a package manager (and most have them now) should be able to just drive Go's package manager.

This is squishy and just my 2 cents. But, we should keep this in mind in the solution.

[Peter Bourgon]

Two related thoughts:

1) UX is abstract; user stories are concrete; let's prefer the latter
whenever possible.

2) "Someone coming from another language with a package manager (and

most have them now) should be able to just drive Go's package

manager." — I'm not sure makes for a great fundamental axiom. If we
can solve the problems hurting our users (as expressed by user
stories) without aiming for feature parity to common package manager
solutions in other ecosystems, I think that's totally viable and
(arguably) even preferable.

> --
> You received this message because you are subscribed to the Google Groups
> "Go Package Management" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to go-package-manag...@googlegroups.com.
> To post to this group, send email to go-package...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Matt Farina]

On Wednesday, August 10, 2016 at 9:53:33 AM UTC-4, Peter Bourgon wrote:

Two related thoughts:

1) UX is abstract; user stories are concrete; let's prefer the latter
whenever possible.

User stories and UX are not mutually exclusive. Someone could design a new car, in keeping with the car analogy, that has a completely new set of driving controls but still fulfills all the needs to steer or otherwise control the car outlined in user stories. Take that to a car market and see how it's received.

UX is abstract which makes it hard to quantify. Yet, can we really ignore the experience of users?

Useful = Usability + Utility

UX and usability are slightly different.

For reference on the difference...

> User experience (UX) refers to a person's entire experience using a particular product, system or service.

and

> In software engineering, usability is the degree to which a software can be used by specified consumers to achieve quantified objectives with effectiveness, efficiency, and satisfaction in a quantified context of use.

 

The reason I'm concerned with UX in addition to usability is because people are watching. Those who aren't adopting Go because of package management needs and those who are frustrated. Package management has been deemed the largest blocker to the adoption of Go with good arguments by numerous people. The experience of this is worth nailing.

2) "Someone coming from another language with a package manager (and
most have them now) should be able to just drive Go's package
manager." — I'm not sure makes for a great fundamental axiom. If we
can solve the problems hurting our users (as expressed by user
stories) without aiming for feature parity to common package manager
solutions in other ecosystems, I think that's totally viable and
(arguably) even preferable.

I can drive a Go-kart around my community or I can drive a luxury sedan. They have radically different features. Driving them is around town is very much the same. Steering wheel, gas, break, and that kind of thing.

I'm not suggesting feature parity. 

Think of this as a general way to describe usability (as defined above) for the masses of devs.

 

> email to go-package-management+unsub...@googlegroups.com.

[Daniel Theophanes]

Matt,

In design class back in college, one tool we were taught to use was the house of quality (HoQ). In a basic form, user requirements went on one axis of the grid, and technical description went on another axis. A matrix was formed to show which technical requirements satisfied user requirements.

The car analogy was a basic example. User requirement: "The door should be easy to close". Technical requirement: "Door should close with less than 5N of force". We then used the technical requirements to drive a design.

If I understand you correctly, you are suggesting adding "similar to other package managers to be familiar" to the user requirement list.

Am I correct in this understanding? If that is correct, could you please also list some of the possible technical requirements that would correlate to that user requirement?

Thanks, -Daniel

[Matt Farina]

On Wednesday, August 10, 2016 at 10:31:40 AM UTC-4, Daniel Theophanes wrote:

Matt,

In design class back in college, one tool we were taught to use was the house of quality (HoQ). In a basic form, user requirements went on one axis of the grid, and technical description went on another axis. A matrix was formed to show which technical requirements satisfied user requirements.

The car analogy was a basic example. User requirement: "The door should be easy to close". Technical requirement: "Door should close with less than 5N of force". We then used the technical requirements to drive a design.

If I understand you correctly, you are suggesting adding "similar to other package managers to be familiar" to the user requirement list.

Am I correct in this understanding? If that is correct, could you please also list some of the possible technical requirements that would correlate to that user requirement?

I'm not sure that "similar to other package manager to be familiar" is quite what I'm getting at. That's a little too broad.

At the moment I just want to plant the idea of User Experience in peoples minds. That it's an experience and technical problem to solve. And, what the context of the experience problem is.

You are right that we should have some technical requirements for this. I'm not quite to that point, yet, because I'm still doing research. More to come on the research front soon.

 

Thanks, -Daniel

[atd...@gmail.com]

Considering Go's own history, and knowing the current constraints of the language and current tooling, it also seems to me wiser to start from first principles.

Especially since one could argue that none of the other languages have really solved the issue of dependency management 100% satisfactorily for their own ecosystems.

That means that we have to agree on our terminology first, since it is going to be specific to us (and may or may not overlap with the terminology used in other ecosystems).

It means that the necessity for each feature needs to be argued.

A lot of people have been tackling the issue on their own, which is great. Scratching their itches. It would be interesting to write up a list of the shortcomings in the current tooling they wanted to deal with. Instead of looking at what is done elsewhere.

I hope that people are ready not to push for their own blessed solution, or other people's solution from the get-go but rather ready to look for advantages and drawbacks in what they implemented. Then we will be able to summarize and hopefully from that, the best solution that works for Go can arise.

One last note: a lot of the tools that have appeared lately are directly insspired by the Go tooling. Whether in Elm or Rust etc. They still have shortcomings in my opinion even though they might be seen as advances. Let's try to focus on what we can do to solve our issues. I'm positive we can find something great.