On Thu, Jan 18, 2007 at 03:14:06PM +0100, Karel Demeyer wrote:
> 2007/1/13, Youness Alaoui <[EMAIL PROTECTED]>:
> > Hello hello...
> > ok, now I remember your mockup! but let's start with NWM's mockup : bad
> > idea, too big, no more CL available, the
> > way yyou did it is good, but as a separate window.
> >
> > now about Karel. I must say, I didn't like it at all. well, I still don't
> > for one main reason : in your mockup
> > those photos/blog posts are from your contact "Vivia", but I know vivia
> > doesn't have any space :p
> > no, seriously, my main concern is that the CL is a CL, it's a contact list,
> > to see your contact and allow you to
> > interact. When you were saying the ccard is bad, I thought 'you may be
> > right, it's too small, clustered, etc.."
> > but I thought the idea would be to have an 'informational window' just like
> > the properties window when the user
> > can clearly see the info he wants. I didn't think you were talking about an
> > embeded thing inside the CL.
> > Your idea, for me at least, is not good because it renders the CL as
> > something else, it doesn't become a
> > "contact list" but a "contact/information list". To me, this idea would be
> > analog to clicking on the "you have
> > 10 new messages in your inbox" button and the CL expands to show you all
> > your emails... the CL is not a
> > browser...
> > it's like a dispatcher, it's there to give you QUICK ACCESS to your
> > contacts, their status and your inbox count.
> > Having that extra info is not in the 'philosophy' of a contact list.
> > I hope I got myself clear enough...
> Well, if you really mean that's the only use for out contactlist, then
> why do we show the music contacts play and how they feel (psm)?
The PSM is part of the user information, it can be "in the shower" or
something, so it is usefull when looking
at the CL.
> >
> > now, I didn't take too much time in reading your posts because.. well, no
> > offense, I just didn't feel like it :)
> > I did read them though but didn't spend much time on trying to understand
> > every dot and commas. The good news is
> > that your idea is not that 'bad', it just doesn't fit in the philosophy of
> > the CL (in MY opinion) BUT it is 100%
> > very good in terms of usability (without considering the fact that the user
> > might say 'wtf is this doing here').
> > Your point about how to rescan the screen, the direction of the parsing of
> > the list, the availability of the
> > info, etc.. I think it all makes perfect sense, the problem is just that I
> > don't know how the users would react
> > to that... I personally would say I prefer a ccard.
> >
> > If we go back in time a little, go back to the early days of my
> > participation in this project, I remember we had
> > some kind of rule : for EVERY new feature, make it optional, for everything
> > that may be done 2 ways, make it an
> > option...
> > actually, it was more of a customization thing and answering every user's
> > needs so you must be able to customize
> > everything your way, if a user asks for your mockup, we do it but as an
> > option, someone asks for a ccard, we do
> > it but as an option.
> > What I would like to propose is to have it both ways. The ccard is really
> > easy, it can be done in a few minutes,
> > I'm sure, I mean the whole code is there already, all we need to do is,
> > when inserting the data in the ccard,
> > add a few lines where we insert additional infos like blog posts and such.
> > Your idea would take a bit more time I would guess, right ? but it won't
> > take too much either.
> > Hummm... I just noticed something, in your mockup, you have that photos/
> > blog posts thing, and it looks exactly
> > the same as how it should go in the ccard, and the new CL is a canvas and
> > the ccard is probably also a canvas,
> > so we could have a proc :
> > proc buildSpaceInfo { canvas x y spaces_info } {
> > .... ;# get the info from $spaces_info and write it to $canvas at $x $y
> > }
> >
> > proc clickOnSpacesButton { email } {
> > if { [config::getKey ccard_in_cl] } {
> > ::abook::setPersistantData $email show_ccard 1 ;# actually invert the
> > old value
> > } else {
> > openCCard $email
> > }
> > }
> >
> > proc openCCard { email } {
> > toplevel .ccard
> > ..........
> > canvas $cvs ...
> > .....
> > buildSpaceInfo $cvs $x $y [GetSpacesInfo $email]
> > }
> >
> > proc drawContact { email } {
> > ...
> > if { [abook::getPersistantData $email show_cccard 0] == 1 } {
> > buildSpaceInfo $pgBuddy.cl [expr $contact_x + 10] [expr $contact_y +
> > 30] [GetSpacesInfo $email]
> > }
> > }
> >
> >
> > that would be it.. we only need to write the code handling that data once.
> > And we could add the option in the
> > appeearance tab of the preferences.
> > What do you think ?
> > Because I am SURE that people will complain about the ccard not being there.
> > + your ccard plugin is so nice, I would really hate to waste it :)
> > but for those who like usability, they can use your method.
> >
> > also, I would say that the first time you click on the spaces button, a
> > window would popup asking you which
> > method you choose, and in order to make it nice, a window like this :
> > -------------------------------------------------------------------------
> > | How do you want to see your contact's spaces information |
> > | |
> > | o In a contact card o Embeded in the contact list |
> > | |
> > | ---------------------------- ------------------------------ |
> > | | | | | |
> > | | | | | |
> > | | | | | |
> > | | Screenshot | | Screenshot | |
> > | | | | | |
> > | | | | | |
> > | | | | | |
> > | ----------------------------- ------------------------------- |
> > | |
> > | [Ok] [Cancel] |
> > | |
> > -------------------------------------------------------------------------
> >
> >
> Well, this makes it again a bad experience for someone using amsn for
> the first time. It's ok we ask for the tab-closing when closing
> chatwins or if he wants to close the app when he closes the main
> window ... as he might care enough of not loosing data (chats when
> not saving logs). But this is just an interface preference... If I
> had to use an aplication for the first timle and ever y time I click
> something it asks me a question I wouldn't use it for long ...
>
I don't really see how it could be a bad user experience, it's a one time
choice, there is no reason why it
would bother a user, especially if he's going to use amsn for a while, and for
such a great feature, I really
don't think it would bother someone (first time you use mouse gestures with
opera, it asks you if you want to
enable them, or disable them, or whatever, and it's fine to ask such a
question). Also, by doing such a popup,
users will know that they have two ways of showing the ccard, either inline or
not and it's important especially
if you don't want the feature to go to waste since not everyone checks the
preferences.
> So, what I had in mind ... we just draw it inline, but there's a
> config var to prohibit this. Whoever likes could make a contactcard
> plugin, reusing some code of aMSN (the drawing of photos etc, cfr
> infra), setting the var to 0 and so when a user clicks the button, a
> ccard is created. We could even ship such a plugin by default, though
> I'd like it to be disabled by default :).
>
Well, I think that that's what YOU had in mind, and it's not what I have in
mind, so why would it be done your
way and not my way. I'm not saying your way is not good, I'm just saying that
over time, I realize that you
really rarely do compromises. I say we make a poll to avoid any
problems/tensions. Your idea of inline, I just
hate it, I really don't think it would go there (but I tried with latest SVN
and it does look nice), and I
really think that a ccard like WLM's would be the best way to go.
Your thing about setting the var to 0 and having a separate plugin is just
stupid IMHO because it complicates
things so much. An option would be so much better, no need for a separate
plugin or whatever, we already put
that in core, why do you want your idea in the core and my idea only as a
plugin???
> > ok, that's a long enough mail for now, and I think (hope) you get my point.
> > Now, what do you guys think ?
> > we need to decide on this so we can move forward!
>
>
>
> >
> > p.s: I think a modular function that writes the ccard info like shown above
> > can already be written until we
> > decide what to choose
>
> I'm now doing it in the guicontactlist.tcl code, but once it's done it
> could be moved to iot's own proc with parameter $canvaswidget and
> $xpos $ypos. But for now, I'm just doing it inside
> guicontactlist.tcl..
>
I don't get it. I saw your code being inside the drawContact proc and it
frustrated me, seriously, what are you
loosing in putting it in a separate proc from the start? it's so much more
complicated and bug-prone to
refactor the code afterwards while it would have taken you only 5 seconds to
create a proc for it. I don't see
why you're being hard-headed on this matter, u got nothing to loose to do it
like I said, even if we were going
to keep the inline thing as default and no popup window asking to choose
between the two methods, then you still
have nothing to loose to do it like I said...
Anyways, apart from that, good job so far, it looks nice!
> Karel.
>
> > KKRT
> >
> >
> >
> > On Sat, Jan 13, 2007 at 02:41:10PM +0100, Karel Demeyer wrote:
> > > Forgot (for my proposal): as it takes some time to fetch all needed
> > > data, on a click, drawContact should only draw a temporary message
> > > like "Please stand by ..." and call the fetching procs ... then after
> > > this, the fetching procs should send an event or call drawContact
> > > again to draw the data...
> > >
> > > 2007/1/13, Karel Demeyer <[EMAIL PROTECTED]>:
> > > > If (and it still has to be chosen, I'm not pushing anything (well, not
> > > > too hard :p)) the choice would be made for inline ccard in CL, this
> > > > has to be done:
> > > >
> > > > * Add an abook var (boolean), not volatile so it 's still there in
> > > > another session, like "CcardShown" for every user. If this is not
> > > > volatile, we have an extra feature over WLM, to keep some user's ccard
> > > > data allways shown, I would like this.
> > > >
> > > > * In guicontactlist.tcl:
> > > > - in proc drawContact, have a check for this var and if
> > > > available, draw the data underneah the contact, according to my mockup
> > > > :)
> > > > - in that same proc, rearrange the tags somewhat. the tag all
> > > > things of the contact have should be added to every item of the space,
> > > > also the stars (it is this way now), for the dragging procs.; a new
> > > > tag should be created and changed in the bindings for clicking on
> > > > those items (all nickname items, statusicon, psm items, statusmsg) to
> > > > open a chatwindow;
> > > > - have a binding on the star that: *toggles the abook var;
> > > > *calls the drawContact proc for that specific contact; *call the
> > > > rearrangeList (or what it's named) proc to move everything
> > > >
> > > > It's not too much work in fact thus. I guess it's less work than
> > > > changing the ccard plugin. An eventual ccard plugin should made
> > > > possible to prevent drawContact from drawing the spaces info (a global
> > > > ::config key "drawSpacesOnCL" maybe) and change the binding of teh
> > > > "star" icon.
> > > > Anyway, I don't have the time to do this. In fact I have a very hard
> > > > exam of one of my Law courses monday so I shouldn't even be mailing
> > > > this but I couldn't resist as I want to lobby for my idea :)
> > > >
> > > > Karel.
> > > >
> > > >
> > > > 2007/1/13, Karel Demeyer <[EMAIL PROTECTED]>:
> > > > > I favour to have this data in the CL as all those new windows only
> > > > > cover up your screen. Added that when we don't want window borders
> > > > > drawn by the windowmanager (and I guess we don't), it means we'll have
> > > > > windows unmanaged by the windowmanager and thus allways on top on teh
> > > > > screen. I, for one, find this very unpleasant. Addded that those
> > > > > windows are not consistent with all other UI apsects on one's
> > > > > computer, I think it's bad UI design.
> > > > >
> > > > > See, when you want to do a task on your PC, you want the UI to enable
> > > > > you to work fast and efficient. If I open this data by clicking on
> > > > > that "star" and the data appears just underneath my pointer, it's very
> > > > > fast to reach with the mouse. If I click, and it opens another
> > > > > window, I have to rescan my screen to find out where to find it's info
> > > > > as it will not be just where I was. Ok, I guess WLM's ccards appear
> > > > > close to the place you clicked... but if they appear under your
> > > > > cursor, it means they cover the data of the CL. If they appear next
> > > > > to the contactlist, they appear further from your pointer and so you
> > > > > have to move your mouse for longer, which is not a good thing.
> > > > > Also, when you scan your CL to find a contact, you go top-down or
> > > > > bottom-up. As in most languages we read top-down, most ppl will scan
> > > > > there CL top-down (sidenote: this is another reasong why I dislike
> > > > > WIndow's start-menu bottom-left). So, if I'm scanning my list, find
> > > > > my friend, click the star, the fastest place to reach for the new info
> > > > > is just underneath it as I was already moving my eyes in that
> > > > > direction... Those seem like small details maybe but in fact it
> > > > > makes life easier for a lot of people. I guess if we implement it
> > > > > this way there will be complaints, just as there are complaints about
> > > > > ever UI design choice (yeah, even if they come from Apple Inc. ;)) But
> > > > > I think it's worth the hassle.
> > > > >
> > > > >
> > > > > Karel
> > > > >
> > > > >
> > > > >
> > > > > 2007/1/13, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> > > > > >
> > > > > >
> > > > > > On 13/01/07, NoWhereMan <[EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > > ----- Original Message -----
> > > > > > > From: "Karel Demeyer" <[EMAIL PROTECTED]>
> > > > > > > To: "Mailing list for developers and everyone helping AMSN"
> > > > > > > <amsn-devel@lists.sourceforge.net>
> > > > > > > Sent: Saturday, January 13, 2007 11:57 AM
> > > > > > > Subject: Re: [Amsn-devel] Contact Cards and MSN spaces
> > > > > > >
> > > > > > >
> > > > > > > >I just implemented an Event for a changed space. Now, I was
> > > > > > > >asking
> > > > > > > > myself ... how do we know when we can unset the star's
> > > > > > > > appearance ?
> > > > > > > > When do we know the blog is read ? When our user clicks the
> > > > > > > > star ?
> > > > > > > > Doesn't the protocol let us know when the blog has no unread
> > > > > > > > items or
> > > > > > > > unseen photos ?
> > > > > > > >
> > > > > > > > Karel.
> > > > > > >
> > > > > > > in MSN7.5 gleam disappears when you click to see the ccard, so I
> > > > > > > guess
> > > > > > that
> > > > > > > once you clicked you can set a local variable read($user) to 1;
> > > > > > > gleams are client-side, so if you set a space to read on a client
> > > > > > > if you
> > > > > > log
> > > > > > > in from another pc you should still see blinking gleams.
> > > > > > >
> > > > > > > about the ccard embedded in CL... I don't know, it would be too
> > > > > > > "compressed"... how about an in-CL ccard ?
> > > > > > > http://i18.tinypic.com/2e5mg02.png
> > > > > > >
> > > > > > > with a "< back" link to the main cl... I don't know maybe it's
> > > > > > > even worse
> > > > > > > than the msn-style ccards :P
> > > > > >
> > > > > > I prefer karel's method :P I don't mind the popup card to be
> > > > > > honest, but I
> > > > > > do think Karel's 'expand-the-contact' thing has a certain appeal :)
> > > > > > I like
> > > > > > it and if we're saying no to the popup card I think we should be
> > > > > > saying yes
> > > > > > to the in-Cl expand thing :P
> > > > > >
> > > > > > > bye
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > -------------------------------------------------------------------------
> > > > > > > Take Surveys. Earn Cash. Influence the Future of IT
> > > > > > > Join SourceForge.net's Techsay panel and you'll get the chance to
> > > > > > > share
> > > > > > your
> > > > > > > opinions on IT & business topics through brief surveys - and earn
> > > > > > > cash
> > > > > > >
> > > > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > > > > > _______________________________________________
> > > > > > > Amsn-devel mailing list
> > > > > > > Amsn-devel@lists.sourceforge.net
> > > > > > > https://lists.sourceforge.net/lists/listinfo/amsn-devel
> > > > > > >
> > > > > >
> > > > > >
> > > > > > -------------------------------------------------------------------------
> > > > > > Take Surveys. Earn Cash. Influence the Future of IT
> > > > > > Join SourceForge.net's Techsay panel and you'll get the chance to
> > > > > > share your
> > > > > > opinions on IT & business topics through brief surveys - and earn
> > > > > > cash
> > > > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > > > >
> > > > > > _______________________________________________
> > > > > > Amsn-devel mailing list
> > > > > > Amsn-devel@lists.sourceforge.net
> > > > > > https://lists.sourceforge.net/lists/listinfo/amsn-devel
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > > -------------------------------------------------------------------------
> > > Take Surveys. Earn Cash. Influence the Future of IT
> > > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > > your
> > > opinions on IT & business topics through brief surveys - and earn cash
> > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > _______________________________________________
> > > Amsn-devel mailing list
> > > Amsn-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/amsn-devel
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys - and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Amsn-devel mailing list
> > Amsn-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amsn-devel
> >
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Amsn-devel mailing list
> Amsn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amsn-devel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel
