Hi,
what I am just seeing is a battle of two ideas and I don't like twice...
I hate MSN Spaces and I don't care if somebody has updated its blog...
I think that MSN Messenger is for Instant messaging and that's all...
I think that all of these things should go in a plugin... The core can provide
functionalities to let plugins get all the information they need but I think
that the displaying code must go in a plugin.
Now, you will say that's not easy but I think you are wrong...
What misses in the newCL code is some splits for some major functions like
drawContact...
For that I have in mind to have several procs to display the several parts of
the contact information...
To help us to have all variables updated, don't forget that Tcl/Tk provides
the upvar command that let you use the variables of the parent functions...
I was thinking about this split since some time and I think I will be able to
do it this week-end...
So if everybody agrees, I propose to put a lock on guicontactlist.tcl as soon
as I will begin to write the code as I don't want to see anybody modify the
code when I am splitting it...
By the way, don't forget that if many users like aMSN, it's because it can
stay light compared to Live Messenger...
Phil
Le Thursday 18 January 2007 17:09, Youness Alaoui a écrit :
> 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
