On Wed, Jan 31, 2007 at 06:47:55PM +0100, Karel Demeyer wrote: > 2007/1/30, Youness Alaoui <[EMAIL PROTECTED]>: > > I like the idea, but I don't like the fact that we would loose the inline > > spaces info, it was a good feature and > > I'm sure (even the poll says so) that many people will like that better. > > I wanted to talk with you on msn about this to make sure I'm not saying > > things wrong, but I'll try to give my 2 > > cents here and now. > > I still think the inline spaces info has it's pros, and it looks nice > too. But, I only thought about 1 think for that design and that was > the spaces info; I forgot to see it in a bigger whole. (the idea > could be reused in some plugin) Now I took a view on all "user related > info and settings" and tried to integrate it to make it all > overseeable, easy and WLM-like for a novice user and powerfull and > still clutter-less for an advanced user. >
Yes, I also think the inline spaces has its pros and I wouldn't want to remove that... Do you think there's a way to put merge the two ideas together in some way ? > > I think the ccard mockup you put was great and I like it like that, but as > > a ccard, nothing more. I agree that > > there are too many informational windows, but I don't think too many is > > bad, too little or too exploded is bad, > > if it's the same info, shown differently, it's ok. the ccard should have : > > nick,psm,,dp,blog info. No need for more info. > > Shouldn't the ccard be the window that shows the info you can show > about that user, instead of only beaing a place to find > blogposts/photos? So, if aMSN has more advanced info, show that info > for more advanced users in that spot ? > ok, well, that's where we didn't understand each other. For me, the ccard is actually the 'spaces info' window, not the 'user properties' window.. the 'user properties' info should actually go in the 'properties' window :p that's why. I understand why you would want to group all that info in one place, but I think that the novice/average user wouldn't want to see *all* that info. I'm sure that a ccard with everything we have on a user will just make the user close the window and not understand. I like the properties window because I think it's still simple while showing a lot of info and is pretty useful. If we are to add the info from there and put it in the ccard, it would become too clutered, not just for the average user, but also for the advanced user. The ccard doesn't have a : email : [EMAIL PROTECTED] nickname : this is the nick psm : this is the psm last login : date last message : date last logout : date it just has the data, without the label telling what is what because it is made so simple that a single look should tell you what is what, you see the blogs, the nickname and psm and you know what it is without the need of the "nickname" or 'psm" label in front of it. If we are to add all the info from the properties window, we'd have to add last login/logout/message, which are 3 dates, and 3 dates would mean nothing without the 'header' label, in which case it will become cluttered. if we have a label for those dates, it makes no sense to not have any header for the nickname/psm/etc.. which means the window will get really huge, and it will become unreadable for the user. I think this is still not good even if that info is only shown in the 'advanced' mode... I prefer to see the ccard as a "spaces info" (we could put that as a title in the ccard info, to avoid confusion) which is why it should be very simple. we should really start calling it 'spaces info' instead of ccard because ccard is just a nickname taken from WLM. I hope we understand each other here. > > > in the mockup, you left the two arrows to 'switch ccard'. I always thought > > the idea of 'switching the ccard' was > > stupid and I would have voted to remove it and leave just a single window, > > not a double sided window. I don't > > know if you'd like this idea but I'll tell anyway, how about all those > > 'extra' informations be put in the > > reverse side of the ccard, like the phone numbers, last login, last > > message, client id, etc.. > > that's optional, it can be left out, but I'm just trying to follow your > > idea of "all the info in the same > > place". > The switch buttons where a mistake, they should be removed :). I > started this mockup from teh old ccards and forgot to remove 'm. > yeah, I knew you forgot them, which is why I said, I wonder if you'd like the idea of actually using the reverse instead of removing it... it was just an idea in order to have all the info in the ccard, because we won't be able to put it all in 'one page' without cluttering the info. > > My opinion is that the properties window should NOT disappear, it's a nice > > window with many useful information > > about a user, and with its multiple tabs we can get access to the alarm > > settings, previous DPs and customize the > > user, nickname/psm/color/dp some advanced otpions, move him from groups, > > etc.. it's useful I think. > If we have a window to show nickname/psm, why not having an option > there to tweak the settings about it ? Same for DP ...? > it's a bit complicated I think, although I may be wrong. when you tweak such a setting, it isn't a field that you just edit. we're talking about custom nick, custom psm, custom friendly name, custom dp, custom color... if it was something internal, like WLM does when storing the adress of someone, or the notes for example, then it's ok, you just edit those notes, but in the case of the custom nick (without talking about all those other custom things) you can't just have a field and edit it because you're not really editing the nickname, you're either setting or unsetting a custom nick, which itself can be made of $nick/$email variables. assuming it's an entry, you can't just click on it and backspace/backspace to edit the nickname, you should end up with an empty entry if no custom nick is set, and then you set it to something. same applies for the other custom options. > > My original idea, and I just found out that WLM does kind of the same (a > > bit differently though). > > My idea was to have the ccard as ou had it in the 'std' mockup, and have, > > instead of the 'advanced' button you > > had, have a "Edit contact" which would open the properties window. > > I think, with NWM's mockup, a "More info" button would also be suitable. > > In WLM, it's acutally a pencil icon and only in the reverse side of the > > ccard, and it's tooltip says "edit this > > contact's information" which opens up some kind of properties window, where > > you can enter > > name/address/phones/nickname/website/birthdays/etc.. and a 'notes' tab :s > > You can only change *this socio-demographic data* in WLM, right ? We > have more info to put on a ccard, so why put it in another window ? > If you want the properties screen to be the "edit contact" screen, you > shouldn't use it to display other data too because then it's more then > an "edit contact" screen. (joke: It's like a filemanager that's also > a webbrowser, those tasks are better split ;) ) > "we have more info.. why put it in another window" -> I'd say because we have too much info that would be totally useless for a user to 'quickly access' that info. you usually don't want to quickly access that info, although I may be wrong... actually what we want to quickly access is already in the tooltip.. no ? "if you want the properties screen to be the edit contact, you shouldn't use it to display other data" -> no, I think it has to contain that data too because as explained above about the difficulty of the custom nick, it's the same thing, you can't edit something if you can't get access to that info at the same time. Also, it's a "properties" window, which means it shows the properties and it allows you to edit them and more, it's not a "edit contact info" window.. at least, that's how i see it, others might see it differently.. > > > > So this is my 2 cents. a button to open the properties window is good, the > > 'advanced' idea is also good but I > > wouldn't want to put too much info in that single window. > Well, you would put it in teh properties window ... so you want it in > 1 window. If you find the ccard a bit too small, it could be made a > (little !) bit bigger by default but we shouldn't overwhelm new users > with all teh advanced options IMO. Eventually we can have an option > to make the ccards I propose always expanded for power users ... Just > ideas! > I think having it 'advanced' always for power users is useless, it's saving one click once in a while for the user but cluttering amsn with yet another option (unless using powertool plugin). I think the ccard is small because it should only contain spaces info, I do think it's a bit too small, and as you say it can be made a (little !) bit bigger... but it would still not be fit enough to contain all the necessary info, don't you think ? > > Karel. > > PS: what I write is my opinion, it's not *the preferable way* maybe How humble :) ;) > > > > > > KaKaRoTo > > > > On Tue, Jan 30, 2007 at 05:57:46PM +0100, Karel Demeyer wrote: > > > 2007/1/30, Cristofaro Del Prete <[EMAIL PROTECTED]>: > > > > My 0.02: > > > > > > > > Karel Demeyer ha scritto: > > > > > Hi, > > > > > > > > > > I'm working on a UI proposal for the ccard's/properties window. > > > > > Firstly I want to make some things clear: > > > > > * this proposal gets rid of "inline" ccards, they were (imo) a nice > > > > > idea UI-wise to show the data but we have more data to show and we > > > > > should make it all a bit more clear and easier. > > > > > * this proposal mostly works like the way youness implemented the > > > > > ccards but tries to make the ccards more in a general "user properties > > > > > screen" > > > > > > > > > > So, what do I propose: When a buddy icon is clicked, a ccard pops up, > > > > > where it should pop up should be thought about as it is important > > > > > interface-wise. A mockup for this ccard is in attachement. This > > > > > ccard already shows a bit more data then WLM's; it shows the email > > > > > addres, a button to change notes, a button to change alarms, an > > > > > "advanced" button .... > > > > > like we have now in the properties screen, everything on this ccard > > > > > should have a right-click menu where one can choose "copy to > > > > > clipboard". For the nickname, psm and display picture, there should > > > > > be a "options" menu-item, clicking this opens another window where > > > > > onne can set custom DPs, or custom nicknames, custom color of a > > > > > nickname etc... > > > > > > > > > > Clicking the advanced button makes the window in what I have in my > > > > > other mockup. Firstly, it adds 3 "edit" buttons, one after nickname, > > > > > psm, and one hovered on a corner op the dp. Clicking those buttons > > > > > does the same as rightclicking the items and choosing "options". > > > > > Another thing that happens when you click the "advanced" button (the > > > > > button should stay pressed then), is the window growing bigger. The > > > > > window should then show firstly some extra data of the user, and then > > > > > allow for some other settings that are special for that user. This > > > > > extra space will probably be a TK frame so it won't have that nice > > > > > background, but that's not such a problem. I didn't add all options > > > > > on my mockup, but you can check our properties window now to see what > > > > > is needed. > > > > > > > > I don't think the contact card should be used to show advanced infos, or > > > > to edit settings. I think it would be better to just have a > > > > "preferences" button, in the left-bottom corner of the ccard, that would > > > > open the user properties windows. > > > > This way there would be fast access to the advanced info (they are in > > > > the first tab), as well as *all* the user settings, instead of just few > > > > of them. > > > The thing that I try is to put all the settings there in teh expanded > > > ccard so we won't need a properties screen anymore. Everyhting should > > > be on teh ccard or a window openened with a button on the expanded > > > ccard. > > > > > > > > > > > > Why do I propose this ? Well, we have to much different ways to show > > > > > user data: I wanted to add inline spaces data (ok, my bad), we will > > > > > have ccards, we have a properties window and we have a tooltip... this > > > > > should be reduced imo. I think the tooltip has too much information > > > > > right now. It should have dp/nick/psm/music and not more I guess. > > > > > > > > I'd also add the contact status, because, when using the small display > > > > pictures in place of the contact icon, it can be difficult to see if a > > > > contact is online or offline. > > > Well, overlaying a status-icon on the ccard's DP should do this. But > > > this should also be fixed in teh new CL. sthe status icons should be > > > overlayed on the buddy icon, so when the buddyicon is changed into a > > > dp, there should still be a status emblem. > > > > > > > > > About this proposal, nick/psm are truncated but they should have a > > > > > tooltip with the full string. > > > > > > > > > > My question now: what's your opinion about this ? What would you like > > > > > differently ? ... > > > > > > > > > > Karel. > > > > > > > > > > PS: I don't have much time now but I did this as a spare time project > > > > > between my study-hours; If I don't respond to e-mail quickly, it > > > > > doesn't mean I'm not interested in your replies thus. > > > > > > > > > > > > ------------------------------------------------------------------------- > > > > 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 ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
