I am pretty much sure that if you look carefully at any friend's timeline profile you can easily predict what going on in his/her life, Even you can write his/her entire life, you can also find out the hidden fact which he/she never told or updated directly but indirectly he/she shared n liked related thing which will help you to analyze his/her activity. Is it anyway possible to build an automated system which can read n analyze friends entire facebook profile, his/her shared stuff, likes, comments etc. and create a report which will expose his/her entire life facts including hidden one, using some AI or Machine learning concepts?
There's no system that will automatically be able to give content and understanding like you're looking for automatically. The human mind is able to infer a lot that computers simply can't understand. Also, you (generally) know some things about the people outside of Facebook (since you are friends with them) that fills in a lot of detail that the analysis system won't have.
The best thing you can do is to clearly define your problem and question that you're asking. There was a 'gaydar' project at MIT that was able to look at networks of students and generally correlate which ones are gay. For large groups you'll find it works overall, but for an individual person you're not going to be able to have great certainty.
Yet, to just ask the computer to 'find hidden information' won't work. You need to have a pretty solid model to work with. Overall, you're probably going to need a lot of data with confirmed facts to get started on testing that model as well (thousands of points needed). Also, with any social network you'll find that there is a lot of inaccurate/fake data on any given social network. People mis-list things all the time for various reasons (humor, etc) and this is going to throw off your models.
Related
For historical and legal reasons (industry funding and contracts), we have proprietary simulation code (that we wrote, some in C and some in python) that we can't make publicly accessible.
However, we want to preliminarily move to a model where at least the functionality of the code is more accessible. I know one model people use is to have people submit jobs to our servers, and we just return results.
However, is there a way where people we've granted access to can use the software on our computing cluster, but not take it with them, e.g. at least in a sandboxed environment so that they may use/debug their use of the code before submitting jobs to the server? Does C/python code make any difference.
I know ideally we'd just make the code open source and not worry about this, but (out of my paygrade) this is not in the cards right now.
Apologies if this question has been asked or if it is super basic -- I'm not sure what the right terminology to use and search with to address this issue.
Thanks!
I recently came across this script that extracts friend rank data from the currently logged-in Facebook profile and presents it as a table.
After trying the script personally, I became puzzled as to why certain individuals were consistently ranked higher than others. The rank seems to refresh daily, so I have experimented with various user interaction, and this shifts many entries appropriately; however, the same 'certain individual(s)' would often (with no discernible interaction) arbitrarily move up in rank.
My question is this: is it possible that this rank is being affected by other, external profile's usage data/habits?
In the interests of privacy, it seems very unlikely that anything but personal habits would influence this ranking, but my own and other peoples' usage anecdotes seem to suggest 'arbitrary' movement that would only be explained by external data.
I cannot seem to find a definitive answer to this elsewhere.
Any input would be greatly appreciated.
When you're logged in, in the page source, there is a list called OrderedFriendsListInitialData.
According to rumour, it's a list of people that visit your profile the most, others say that it's a list of profiles you view the most, and yet other say it's the friends you interact with the most.
Can anyone shed some light on this by providing a definitive answer, or at least an educated one?
If You check the code You will notice it has something to do with right sidebar. Just before it in there is this url https://s-static.ak.facebook.com/rsrc.php/yT/r/q-Drar4Ade6.ogg
As it is JSON string obviously it has to be related, file this url is pointing at is sound notification for chat.
As You may notice it is initial data not chat list probably later chat script use this data to fill up people on list and make some extra check etc..
There is word ordered as well, Myself I'm not really active on facebook so have no way of checking it but it is known that fb analyses all Your steps and make this list based on thousands of factors to provide You with list of users You are likely to chat.
You father may be there because fb knows You are family and consider it as high possibility of conversation.
Send email to them If You want details.
Well in the time passed since you first posted this they've changed the name of the list to InitialChatFriendsList which I suppose is a little more descriptive of what it is, but as far as how they determine what to put on there I think my friends and I have come up with a very plausible explanation.
When determining who you are most likely to communicate with on their chat system, facebook will obviously use a whole number of factors weighted differently to determine who you most want to talk to and who you most need to talk to.
the most important is who you actually talk to... who on fb chat that you communicate with most frequently will obviously show up on your chat list.
who you have public interactions w/ (i.e tagging in at some location, picture tagging, actual wall comments etc.)
Now those two are two very large factors when determining who they put on your list, beyond that it is a combination of who looks at your page and whose page you look at. Based on my list and the list of my friends, we determined that if you are inclined to look at somebody else's page/posts a lot and they are likely to do the same for you, they will move up in rank even if you don't have an actual interactions on facebook. A couple of people who I would admit to "stalking" the most on fb are not even on my list (at least not on the top 50 which is where i stopped checking) while other people who I do occasionally look at and I have reason to believe they would be looking at my profile as well are fairly high on my list (around 10-15th place). And of course there are the completely random individuals who show up on the list who probably are stalkers.
Anyways, my point is there are so many factors that determine who is going to be on this list, you really can't just attribute it all to people who stalk you and people you stalk. While in for some people that would be the case, for most of the people on the list there is a whole list of reasons they're on there.
Of course this is all based on a very small pool of data, so who knows...
I think it may be the list of people who are on the top part of your chat list - the people you're statistically most likely to talk to. But! I may be wrong.
It definitely is the people who facebook considers are the most likely you are going to chat with. There are two lists of people in chat, one of the above, and the other friends who are online.
I believe the first 3 are accurate. When I checked for myself, my boyfriend was one, and my two best friends were 2 & 3. Everything after that seems to be a bit random, because #4 was a person I haven't interacted with for years.
As I'm starting to develop for the web, I'm noticing that having a document between the client and myself that clearly lays out what they want would be very helpful for both parties. After reading some of Joel's advice, doing anything without a spec is a headache, unless of course your billing hourly ;)
In those that have had experience,
what is a good way to extract all
the information possible from the
client about what they want their
website to do and how it looks? Good
ways to avoid feature creep?
What web specific requirements
should I be aware of? (graphic
design perhaps)
What do you use to write your specs in?
Any thing else one should know?
Thanks!
Ps: to "StackOverflow Purists" , if my question sucks, i'm open to feed back on how to improve it rather than votes down and "your question sucks" comments
Depends on the goal of the web-site. If it is a site to market a new product being released by the client, it is easier to narrow down the spec, if it's a general site, then it's a lot of back and forth.
Outline the following:
What is the goal of the site / re-design.
What is the expected raise in customer base?
What is the customer retainment goal?
What is the target demographic?
Outline from the start all the interactive elements - flash / movies / games.
Outline the IA, sit down with the client and outline all the sections they want. Think up of how to organize it and bring it back to them.
Get all changes in writing.
Do all spec preparation before starting development to avoid last minute changes.
Some general pointers
Be polite, but don't be too easy-going. If the client is asking for something impossible, let them know that in a polite way. Don't say YOU can't do it, say it is not possible to accomplish that in the allotted time and budget.
Avoid making comparisons between your ideas and big name company websites. Don't say your search function will be like Google, because you set a certain kind of standard for your program that the user is used to.
Follow standards in whatever area of work you are. This will make sure that the code is not only easy to maintain later but also avoid the chances of bugs.
Stress accessibility to yourself and the client, it is a big a thing.
More stuff:
Do not be afraid to voice your opinion. Of course, the client has the money and the decision at hand whether to work with you - so be polite. But don't be a push-over, you have been in the industry and you know how it works, so let them know what will work and what won't.
If the client stumbles on your technical explanations, don't assume they are stupid, they are just in another industry.
Steer the client away from cliches and buzz words. Avoid throwing words like 'ajax' and 'web 2.0' around, unless you have the exact functionality in mind.
Make sure to plan everything before you start work as I have said above. If the site is interactive, you have to make sure everything meshes together. When the site is thought up piece by piece, trust me it is noticeable.
One piece of advice that I've seen in many software design situations (not just web site design) relates to user expectations. Some people manage them well by giving the user something to see, while making sure that the user doesn't believe that the thing they're seeing can actually work.
Paper prototyping can help a lot for this type of situation: http://en.wikipedia.org/wiki/Paper_prototyping
I'm with the paper prototyping, but use iplotz.com for it, which is working out fine so far from us.
It makes you think about how the application should work in more detail, and thus makes it less likely to miss out on certain things you need to build, and it makes it much easier to explain to the client what you are thinking of.
You can also ask the client to use iplotz to explain the demands to you, or cooperate in it.
I also found looking for client questionnaires on google a good idea to help generate some more ideas:
Google: web client questionnaire,
There are dozens of pdfs and other forms to learn from
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm working in a small company and weeks away from deploying a web-app that will be used a lot. Everyone at one location will have to learn to use it, and although I think it's pretty easy and intuitive I may be biased.
I've written a help guide with plenty of screenshots that's available on every page, but I'll still need to train everyone. What's the best way? How do you take a step back and explain code you've been working on for weeks?
First try to avoid the training:
Perform usability testing to ensure your web app is intuitive. Usability testing is a very important aspect of testing and it is often ignored. How you see your system will probably be very different as how a new user sees your system.
Also add contextual help as often as you can. For example when I hover over a tag in stack overflow, I know exactly what clicking it will do, because it tells me.
Also this may seem obvious, but make sure you link to your documentation from the site itself. People may not think of looking in your documentation unless its right in front of their eyes.
About training documentation:
Try to split up your material into how your users would use the system. I personally like the "trails" option that Sun created for their Java tutorials. In this tutorial you can do several things, and you can chose on which trail you'd like to go.
Support random reads in your help documentation. If they have a task to do in your web app, then they should be able to get help on that without reading a bunch of unrelated content.
Make sure your documentation is searchable.
About actual training sessions:
If you are actually performing training sessions, stay away from explaining anything related to your code at all. You don't need to know about the engine to drive a car.
Try to split up your training sessions into very focused aspects of your system. If you only have 1 training session available to you then just do one specialized use case of your system + the overall description of the system. Refer to the different parts of documentation where they can get help.
Letting the community help itself:
No matter how extensive your documentation is, you'll always have cases that you didn't cover. That's why it's a good idea to have a forum available to all users of the system. Allow them to ask each other questions.
You can review this forum and add content to your documentation as needed.
You could also open up a wiki for the documentation itself, but this is probably not desirable if your user base isn't very large.
Few ideas:
Do you have some canned walk-through scenarios? Don't know if it is applicable for your product, but I built a pretty substantial product a couple years ago and developed some training modules that they'd work through - nothing long, maybe 15 minutes tops for each one.
I put together a slide presentation that hit the highlights to talk about what it does. I would spend about 10 minutes going through the app's highlights to familiarize them with it before doing the hands-on stuff.
People don't tend to read stuff, unfortunately. You could put hours and hours into a help document, and still find that folks simply don't read it or skim over it. That can be frustrating. Expect that answers that are in your guide will be the topic of questions your users will have.
Break up any training you do into manageable chunks. I've been to a full-day training exercise before and the trainer broke it into short pieces and made it easy for me to get the training topic in my head. You don't want to data-dump on them because their eyes will gloss over and you'll lose them.
Ultimately, if your app is highly usable, it should be a piece of cake. If it isn't, you'll find out. You might want to have a few folks you know run through your training ahead of time and give you constructive criticism on it. Better to fix it before the big group is trained. You'll be more confident in the product and the training materials (whatever they are) and you'll likely have a better training experience.
If applicable, provide an online help/wiki/faq for them. Sometimes that is helpful.
Best of luck!
You should really have addressed this issue a lot earlier in the development cycle than you are doing.
In my view the ideal scenario for corporate software is one where the users design their own application and write their own documentation and I always try to strive for this. You should have identified key users early on and designed the system with them (I try to get my users to do basic screen designs and menu layouts in Excel or similar - then I implement that as static pages and review before writing a line of significant code, obviously they won't get the design right first time, but it's your job to guide them - and ideally in a way where they think they came up with the correct design decisions, not you :-) ).
These users should then write the user documentation from this design in parallel with you developing the system. I have never seen help documentation delivered by a IT department/software company used significantly in a corporate setting. Instead what happens is the users will create their own folder of notes and work-arounds and refer to this (in fact if you're ever doing system analysis to replace an existing system finding the 'user-bible' for the old system is a key strategy). Getting the users to write their own documentation up-front simply harnesses what will happen anyway - but this is vastly easier if the users feel they have ownership of the system because they designed it themselves in the first place.
Of course this approach needs commitment and time from your users, but generally it's not that hard a sell. It's trite, but working as a facilitator so the users can develop there own system rather than as a third party to give them a system pretty much guarantees user acceptance.
As you are where you are you're too late to implement all of this, but if you can identify a couple of keen, key, users and get time from them to write their own documentation then that would be a good move. If you can't get even that then you need to identify an evangelist who you can train to be the 'departmental' expert and give them 110% of your energy to support them.
The bottom line is that user acceptance is based on perception, and this does not necessarily correlate with how usable an system actually is. You have to focus on the group psychology of this as much as the reality of the system, which tends to be tricky for developers as we're much more factually based than most people.
I'll be looking into something like this too in the next few months.
In your case, hopefully the UI has already undergone user acceptance testing. You say you work in a small company. Is it possible to get the least tech-savvy person there to try it out? In fact, get them to try it out without any guidance from yourself except for questions they ask. Document the questions and make sure your user-guide answers them.
The main thing for me would be logic and consistency. If the app's workflow relates logically to the task it has been designed to accomplish and the UI is consistent you should be OK.
Create a wiki page to describe the use of your system. Giving edit rights to the users of your system lets the users:
update the documentation to correct any errors in the initial release of documentation,
share any tips on usage they may have found.
share unusual uses for the system that you may not have thought of.
request features.
provide any workarounds they've found while waiting for the new functionality to be implemented.
Try a few users first, one or two in a small company. Mostly watch, help as little as possible. This tells you what needs to be fixed, and it creates an experienced user base - so you are not the "training bottleneck" anymore.
Turn core requirements/use cases/storycards into HowTo / walkthroughs for your documentation.
For a public training, prepare a 10..15 minute presentation (just that, not more!) that covers key concepts that the users absolutely must understand, than show your core walkthroughs. Reserve extra time for questions about how to solve various tasks.
Think as a user, not as a techie: - noone cares if it's a SQL database and you spent a lot of time to get the locking mechanisms right. They do care about "does it slow me down" and "does something bad happen when two people do that at the same time". Our job is to make complicated things look easy.
It may help to put the documentation on the intranet in an editable form - page "comments", or wiki maybe. And/or put up a "error wiki" for error messages and blips - where you or your users can quickly add recomendations, workarounds and reasons for anything that does not go as expected.
Rather then train all those people I have chosen a few superusers (at least one person from each department) and trained them to teach the rest of the employees. It is of course vital that those super users are
well respected in their departments
able to teach
like the application
The easy way to ensure that they like the app is to have them to define the way it should work :-). Since they should work with this app each and every day they are the prime stakeholders, no matter what management states