Re: Proposal about SqueakMap etc (was Re: [squeak-dev] Re: SqueakMap soon working in 4.0/4.1!)
Locked
Re: Proposal about SqueakMap etc (was Re: [squeak-dev] Re: SqueakMap soon working in 4.0/4.1!)
 
|
I like all of that. I think what you're saying is really constructive. By the time I finished reading your post, I started to think SqueakMap has the possibility to be pretty exciting.
My only real animus here is against implementing what we've had before without any modification or change. I want to see some kind of evolution here and the things you're proposing sound worthwhile.
I think my problem is with the user interface. Three ways to get code ( Thank you but I will "Über einen Kamm scheren" - "lump together" from Google Translate) on one menu is odd. It screams legacy.
I think it comes down to this: I will not like things I don't understand and which nobody justifies the existence of. I use SqueakSource every day. I've been burned by SqueakMap.
1. Include some instructions in the image regarding "how to get stuff" into the image. Seems like a good short term thing to do for 4.1. We can easily explain the difference between SS and SM. PU (as it was called earlier - Package Universes) is ... well, see below. I like that we're moving in a constructive direction, but I don't know that written documentation is the key. It doesn't make sense to me if we're explaining weird UI design. In a way, UI design is documentation. 2. Possibly throw out Universes in 4.1 *iff* it does not work anymore and noone can fix it. I haven't even tried it. Does it work? I'm all for that. It's a bold stroke, and I like that kind of thing. And if we have two points of entry instead of three, that sounds good to me. And if that can be done without losing the value (to some people) of the UB, then everybody wins. 3. Regardless of when we throw out Universes we should improve SM to cover the "loss" of it. Sounds good. 4. Improve SqueakMap. There is a loooong list of things we could do. One thing of immediate interest given this discussion is to make it "mirror" SS somehow so that packages hosted on SS are searchable and installable from SqueakMap Package Loader and listed on map.squeak.org etc etc. We could also revive the "Make release on SqueakMap"-button that used to be in SS so that it can be used for *real* releases and not just for all new versions. Chris? Others? I like all of this. I think these are really great ideas. My sole objective is to see this area of our world reformed in a way that is in keeping with all that has been accomplished in the new image. I understand how intense I've been. And I can see policial capital or goodwill that I may have had on Squeak-dev on fire all around me. But if that was the price necessary to generate the exciting reforms Goran has now proposed. I'd do it again. Chris |
UI design (Re: Proposal about SqueakMap etc (was Re: [squeak-dev] Re: SqueakMap soon working in 4.0/4.1!))
|
|
Chris Cunnington wrote:
> [...] UI design is documentation. Can I have that on a T-shirt, please? Because that's one awesome sentence. (To hark back to a thread from last week-ish, it's also why I like the Browser buttons - they tell me what I can do in a very immediate way.) frank |
Re: Proposal about SqueakMap etc (was Re: [squeak-dev] Re: SqueakMap soon working in 4.0/4.1!)
|
|
In reply to this post by Chris Cunnington
Chris Cunnington wrote:
> I like all of that. I think what you're saying is really constructive. > By the time I finished reading your post, I started to think SqueakMap > has the possibility to be pretty exciting. Problem is: talk is cheap, code is time. > My only real animus here is against implementing what we've had before > without any modification or change. I want to see some kind of evolution > here and the things you're proposing sound worthwhile. Since I know how little time I have to spend I need to make baby steps - and one baby step is to make SM just *work* again. > I think my problem is with the user interface. Three ways to get code ( > Thank you but I will "Über einen Kamm scheren" - "lump together" from > Google Translate) on one menu is odd. It screams legacy. Well, I think it comes down to naming. If SM was called "Package catalog" and MC was called "Source Code Management tool", then perhaps it would not be totally confusing. > I think it comes down to this: I will not like things I don't understand > and which nobody justifies the existence of. I use SqueakSource every > day. I've been burned by SqueakMap. > > 1. Include some instructions in the image regarding "how to get stuff" > into the image. Seems like a good short term thing to do for 4.1. We can > easily explain the difference between SS and SM. PU (as it was called > earlier - Package Universes) is ... well, see below. > > > I like that we're moving in a constructive direction, but I don't know that written documentation is the key. It doesn't make sense to me if we're explaining weird UI design. In a way, UI design is documentation. Sure, but people need to understand the difference of an SCM tool and a package catalog. And one easy way is to tell them. :) > 2. Possibly throw out Universes in 4.1 *iff* it does not work anymore > and noone can fix it. I haven't even tried it. Does it work? > > > I'm all for that. It's a bold stroke, and I like that kind of thing. And if we have two points of entry instead of three, that sounds good to me. And if that can be done without losing the value (to some people) of the UB, then everybody wins. > > 3. Regardless of when we throw out Universes we should improve SM to > cover the "loss" of it. > > Sounds good. We can create a separate thread for the PU "issue". To see if anyone uses it, if Lex is around, what people think etc. > 4. Improve SqueakMap. There is a loooong list of things we could do. One > thing of immediate interest given this discussion is to make it "mirror" > SS somehow so that packages hosted on SS are searchable and installable > from SqueakMap Package Loader and listed on map.squeak.org <http://map.squeak.org> etc etc. We > could also revive the "Make release on SqueakMap"-button that used to be > in SS so that it can be used for *real* releases and not just for all > new versions. Chris? Others? > > I like all of this. > > > I think these are really great ideas. My sole objective is to see this area of our world reformed in a way that is in keeping with all that has been accomplished in the new image. I understand how intense I've been. And I can see policial capital or goodwill that I may have had on Squeak-dev on fire all around me. But if that was the price necessary to generate the exciting reforms Goran has now proposed. I'd do it again. And I ask again, can you help me in doing any of this? regards, Göran |
Re: Proposal about SqueakMap etc (was Re: [squeak-dev] Re: SqueakMap soon working in 4.0/4.1!)
|
|
One of the "big ideas" of Package Universe is that a universe is only for one version of the image. In other words, there was a PU for 3.9 and one for 3.11. If you are going to use PU in 4.1 then you will have to set up a universe for it.
The nice thing about thie idea is that within a universe, you can pretty much expect all the packages to work together. You con't have to search for the right version to load. You just say which packages you want, and the system will load all the prerequisite packages, and get the right version of each. The downside, of course, is that people have to keep making new PUs for each release. PU is easier for the users than SM, but more work for developers. -Ralph |
Re: UI design (Re: Proposal about SqueakMap etc
|
|
In reply to this post by Frank Shearar
>>>>> "Frank" == Frank Shearar <[hidden email]> writes:
>> [...] UI design is documentation. Frank> Can I have that on a T-shirt, please? Because that's one awesome Frank> sentence. Back when I was first learning technical writing from some very smart people, our mantra was: The manual *is* the product. As in, if it's not documented, it *doesn't* exist for the user. And if it's a good product but badly documented, it will be *perceived* as a bad product. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion |
Re: Proposal about SqueakMap etc (was Re: [squeak-dev] Re: SqueakMap soon working in 4.0/4.1!)
|
|
In reply to this post by Ralph Johnson
Hi!
Ralph Johnson wrote: > One of the "big ideas" of Package Universe is that a universe is only > for one version of the image. In other words, there was a PU for 3.9 > and one for 3.11. If you are going to use PU in 4.1 then you will have > to set up a universe for it. > > The nice thing about thie idea is that within a universe, you can pretty > much expect all the packages to work together. You con't have to search > for the right version to load. You just say which packages you want, > and the system will load all the prerequisite packages, and get the > right version of each. Yes, and my idea for "marrying" PU and SM was simply to create a new kind of "package" in SM which is a "Universe". Because if we disregard the tooling/UI etc - a Universe could be equal to a list of SM package releases that work fine in a given image. Simple as that. Now, sure, we still need some rudimentary dependency mechanism - but I still am convinced that the above would work fine. Since SM allows assigning people as co-maintainers etc, a small group of people could maintain such a "list" together, and it would of course be independent of other such Universes etc. The BIG upside of this is that the actual releases and packages are maintained ONCE, and not in two redundant places (SM and PU). > The downside, of course, is that people have to keep making new PUs for > each release. PU is easier for the users than SM, but more work for > developers. Indeed. Also, SM does have a mechanism to categorize releases for a specific Squeak image - but it was not used that much. So depending on people to do "the right thing" is ... a risky thing :) regards, Göran |
Re: Proposal about SqueakMap etc (was Re: [squeak-dev] Re: SqueakMap soon working in 4.0/4.1!)
|
|
2010/4/8 Göran Krampe <[hidden email]>
Hi! Yes, that would be very valuable. Now, sure, we still need some rudimentary dependency mechanism - but I still am convinced that the above would work fine. Since SM allows assigning people as co-maintainers etc, a small group of people could maintain such a "list" together, and it would of course be independent of other such Universes etc. And the other thing that PU provided was a dependency mechanism. If you had both of those, you would eliminate the need for PU. The BIG upside of this is that the actual releases and packages are maintained ONCE, and not in two redundant places (SM and PU). Yes. And one of the problems with PU was that it causes people to stop putting things in SM, so not only did PU never have a goal of having a complete set of packages, but it detracted from SM reaching that goal. -Ralph |
|
|
In reply to this post by Randal L. Schwartz
Yeah but that was back when people actually read stuff. They don't seem to do that anymore. In the past year or so I started using several new (to me) quite complex products, and I didn't read the documentation to *any* of them. I expected them to be designed in an intuitive enough way so that I can learn along as I'm using them. Even when I got stuck with something, I went to look to the forums, youtube, tutorials, whatever before I turned to the written documentation coming with the product (if at all). As people get more ADD, stuff is either obvious for them to figure out or they move on. Give me a well designed product without a manual and I'll be happy using it. Give me a badly designed product and I'll find something else to do. The manual isn't the deciding factor. rado On Thu, 8 Apr 2010, Randal L. Schwartz wrote: >>>>>> "Frank" == Frank Shearar <[hidden email]> writes: > >>> [...] UI design is documentation. > > Frank> Can I have that on a T-shirt, please? Because that's one awesome > Frank> sentence. > > Back when I was first learning technical writing from some very smart > people, our mantra was: > > The manual *is* the product. > > As in, if it's not documented, it *doesn't* exist for the user. And if > it's a good product but badly documented, it will be *perceived* as a > bad product. > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> > Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. > See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion > |
|
|
On 4/8/10, radoslav hodnicak <[hidden email]> wrote:
> > Yeah but that was back when people actually read stuff. They don't seem to > do that anymore. > In the past year or so I started using several new (to > me) quite complex products, and I didn't read the documentation to *any* > of them. Yes, going for a first run. But later on I like to have something at hand. In particular summaries and cheat sheets. What about including the Terse Guide to Squeak? http://wiki.squeak.org/squeak/5699 > I expected them (products) to be designed in an intuitive enough way so that > I can learn along as I'm using them. > Even when I got stuck with something, > I went to look to the forums, youtube, tutorials, whatever before I turned > to the written documentation coming with the product (if at all). I consider a tutorial to be part of the product documentation. And the Pharoistas seemingly do that as well.... :-) > Give me a well designed product without a manual and I'll be happy using > it. > Give me a badly designed product and I'll find something else to do. > The manual isn't the deciding factor. What I always liked about Perl is that it had and has a good documentation. (I see your comment forthcoming ... :-) And let's repeat what is written below "UI design is documentation." As for 4.1 the UI design has much improved. In particular I like the search box. Hannes > On Thu, 8 Apr 2010, Randal L. Schwartz wrote: > >>>>>>> "Frank" == Frank Shearar <[hidden email]> writes: >> >>>> [...] UI design is documentation. >> >> Frank> Can I have that on a T-shirt, please? Because that's one awesome >> Frank> sentence. >> >> Back when I was first learning technical writing from some very smart >> people, our mantra was: >> >> The manual *is* the product. >> >> As in, if it's not documented, it *doesn't* exist for the user. And if >> it's a good product but badly documented, it will be *perceived* as a >> bad product. >> >> -- >> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 >> 0095 >> <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> >> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. >> See http://methodsandmessages.vox.com/ for Smalltalk and Seaside >> discussion |
Re: Proposal about SqueakMap etc (was Re: [squeak-dev] Re: SqueakMap soon working in 4.0/4.1!)
|
|
In reply to this post by Chris Cunnington
I stand by my praise of SqueakMap, however I just saw this e-mail and
wanted to say I didn't intend to re-elevate rhetorical tension after you'd already diminished it. I was reading the list in chronological order.. Not even Göran got as worked up as I did.. On Thu, Apr 8, 2010 at 7:55 AM, Chris Cunnington <[hidden email]> wrote: > I like all of that. I think what you're saying is really constructive. By > the time I finished reading your post, I started to think SqueakMap has the > possibility to be pretty exciting. > My only real animus here is against implementing what we've had before > without any modification or change. I want to see some kind of evolution > here and the things you're proposing sound worthwhile. > I think my problem is with the user interface. Three ways to get code ( > Thank you but I will "Über einen Kamm scheren" - "lump together" from > Google Translate) on one menu is odd. It screams legacy. > I think it comes down to this: I will not like things I don't understand and > which nobody justifies the existence of. I use SqueakSource every day. I've > been burned by SqueakMap. > > 1. Include some instructions in the image regarding "how to get stuff" > into the image. Seems like a good short term thing to do for 4.1. We can > easily explain the difference between SS and SM. PU (as it was called > earlier - Package Universes) is ... well, see below. > > I like that we're moving in a constructive direction, but I don't know that > written documentation is the key. It doesn't make sense to me if we're > explaining weird UI design. In a way, UI design is documentation. > > 2. Possibly throw out Universes in 4.1 *iff* it does not work anymore > and noone can fix it. I haven't even tried it. Does it work? > > I'm all for that. It's a bold stroke, and I like that kind of thing. And if > we have two points of entry instead of three, that sounds good to me. And if > that can be done without losing the value (to some people) of the UB, then > everybody wins. > > 3. Regardless of when we throw out Universes we should improve SM to > cover the "loss" of it. > > Sounds good. > > 4. Improve SqueakMap. There is a loooong list of things we could do. One > thing of immediate interest given this discussion is to make it "mirror" > SS somehow so that packages hosted on SS are searchable and installable > from SqueakMap Package Loader and listed on map.squeak.org etc etc. We > could also revive the "Make release on SqueakMap"-button that used to be > in SS so that it can be used for *real* releases and not just for all > new versions. Chris? Others? > > I like all of this. > > I think these are really great ideas. My sole objective is to see this area > of our world reformed in a way that is in keeping with all that has been > accomplished in the new image. I understand how intense I've been. And I can > see policial capital or goodwill that I may have had on Squeak-dev on fire > all around me. But if that was the price necessary to generate the exciting > reforms Goran has now proposed. I'd do it again. > > Chris > > > > > > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |