U + I = UI

I recently had to change my cell phone service provider. I would never have left Verizon (still claim they are the best) but somehow their service around my home sucks! So I mentally prepared myself for a phone. No digging deep into my pockets for a device which will play mp3's, allow me to IM, serve as a camera + video camera, have some colored tooth, internet browsing, windows media player etc. which also serves as a phone. Bottomline - control the geek in me..... and of course, spend minimum.

I ended up buying the Sony Ericsson Z-500a.

Now I am sitting home looking at this phone comparing it to my LG VX6000. OK, for its price and features, the phone aint bad at all. It lacks the the classy look of the LG. But the bad part is some of its design features.

Lets take this a little further. On your cell phone, you get into "Menu" and then hit "Contacts". Mostly you will have a list which will read as - "List Contacts", "New Number", "New E-mail", etc. Gee, now you realise that this aint what you were looking for. You were looking for the camera feature of this phone.

Next logical step: Hit Clear or CLR or "C" (as seen in most of the phones).

The user model of the clear button or anything which says "C" is you either go back to the previous screen or just clear out to your main screen. Oh well, thats how it has been with my LG and the phone we have back in India.

Back to the Z-500a. Hit the key "C" and the screen just stares at you. Hit it again and still no effect. Now look closely at this picture.

The Z-500a




There are 4 round buttons. The round button the green arrow points to is "C" or clear/cancel (whatever you wanna call it). The red arrow points to a button which had a u-turn shaped arrow on it. I figure this means "Back". So here is the key. Hitting "C" will not clear the screen or rollback. There is a special key to take care of this functionality. So whats the "Clear" key for? When you type in text and if you type texy instead of text and wanna clear the "y", you use clear.

Well, as a concept, its pretty clear. But for someone used to the "Clear" key taking care of everything, its frustrating. You hit the "C" key and wait. Then you hit it again and wait. You think something is wrong with the key. Finally you realise you have been hitting the wrong key. Is the UI bad? No. Its not. So that means the LG UI was bad? No, that was not bad either.

Eh? Am I actually going to learn anything from this post then?

Lets go back to what we are good at. Computers. Operating Systems. The Mac and Windows. Imagine if in the Mac, if you have to move a window, you can grab it by any edge and move it. In Windows, you need to move it using the title bar. For a Windows user working on the Mac, a task of resizing the window will result in moving the window. Very very frustrating. And you say the Mac is known for a poor UI? Of course not. Anything which comes out of the Apple store is known for its pretty face. The world claims the Mac to be pretty and Windows to be loaded with features. But thats a story for another time. The point here is ease of use.

Hmmmm... now we are getting somewhere. I might actually learn something out fo this.

In UI design, you have to see two aspects. User model and Program Model. You have to match the user model.



If your Program Behaves the Way users thought it would, then you have a well designed UI.




The mac OS works perfectly fine.... for Mac users.

The UI design has to be made keeping U and I in mind. You, I and the others. Usually ten of us.


Oh, by the way, the Z-500a does have a camera, video recorder, IM, web browsing, speaker phone, media, etc. And only worth $50. Not bad eh? Of course, I dont know if I am going to stick to it... that "C" key is very frustrating indeed.

I help, You Help. You Help, I Help!

Till now I have been rambling about how it is important to have a good customer focus and how its really important to nail down the specs. Get something wrong and suddenly you are the target of a lot of customer ire. Ship a product with a glaring bug and find yourself losing a big chunk of your market share. But how much ever perfect one would try to be, a product will be shipped with bugs.

Today let me talk about how you, as a customer could help in making a better software.

Report bugs. Its simple.

Lets take Visual Studio as an example. A very well made software (yes, I know there are bugs, but looking at the complexity of the system - I think some bugs are expected). But here is how you can help. When you are working happily along and a terrible crash occurs, a much dreaded dialogue comes up which says something like -
“Microsoft Development Environment has encountered a problem and needs to close.”

And then a little farther down it says…

“Please tell Microsoft about this problem.

We have created an error report that you can send to help us improve Microsoft Development Environment. We will treat this report as confidential and anonymous.

To see what data this error report contains, click here.”

Then you see three buttons: Debug, Send Error Report, and Don’t Send.

Now this is where as a customer/user you could help. After all you are using the product. So why not make it better? Finally its for your benefit!

The above mentioned is known as Watson. When you hit the "Send Error Report" a minidump is sent to the server at Microsoft.

Why am I saying all this? Because I have seen people hit - "Dont Send". I know co-workers (where I work as of 20 March 2005) who spend a long chunk of their day on MS Word and have many crashes. When the Watson Dialogue pops up, they just say "Damn Word" and hit the dont send.

Unfortunately not many people know about Watson. I am sure if they knew what happens behind the scenes they would hit the "Send" button. Altho nothing can be as clear as - "Please tell Microsoft about this problem." But the user is anyways pissed off with Microsoft since what he was working on crashed (consider this user to be someone not highly adept in computers). Now when he finds another screen saying "report the problem" - irritated users says "NO". Dont ask me why - but I have seen this mentality.

Similiar with the Google pop-up blocker. Google suggests that if some pop-up manages to pass through the blocker, to report it. What page you found the pop-up on and properties. Now, how many of us would actually report that? Very few! How many would say "Damn this pop-up blocker!!!" whenever a pop-up appears? I see all hands go up.

This is a two way process. Software teams can only provide you a certain level of security. Testers try to advocate for every end user. But unfortunately thats not possible. The end user has to help the tester too. I can help you only if you can help yourself. The next time - do yourself a favor and hit that "Send Error report" button. After that you have the full right of saying - "Damn ".

The First Tiny Steps

A reader left a comment on Michael Hunters blog asking how one could develope into a SDET (Software Design Engineer/Test) when his day job does not have much scope for automation. Michael provides him a simple answer which says to make it his night job. heh!

Reading this makes me relate to a few days back when we were preparing the final validation documents for submission. Unfortunately I cant go into details till our press release but I'll talk about something very similiar.

As a new employee 2 months ago I did notice that no one is really a big fan of automation. Some places do not need automation but some places could do with automation. Unfortunately I had not been able to convince my manager to automate a few things I felt should be automated. But that didnt stop me from thinking up other ways to get his attention towards automation.

When we are making our daily runs/builds

• All programs lie in the PROGRAM folder.
• All Logs (of corresponding programs) lie in the LOG folder
• The outputs of the programs lie in the OUTPUT folder.
  
  

Fortunatly when we laid out the specs, we put forward a naming convention for the three. An example would be, for an output the corresponding programs and logs will be:
Program : ABCD 1.2.3.sas
Output : Table 1.2.3.doc
Log : ABCD 1.2.3.log

The final stages of our submissions process is something like this:
A folder is created for every set of program, output and log. This folder will be named the same as the output file, taking off the extension .doc. So our validation folder would carry another folder with the name Table 1.2.3 and this folder will contain the above three files along with other documentation.

Now the poor programmers (myself included) who wrote the programs are the ones responsible for making this folder with the above documents. So if you walk into a programmers office when he is creating this structure, this is generally what you find on his screen. Four windows of Windows Explorer open, having the program, log, output and validation folder. Then he searches through the list of programs and identifies the one he wants, copies it into the validation folder. Ditto for log and output. Then he realises he has to do that for another 80 more programs/logs/outputs... turns around, takes out his revolver and shoots you in frustration! After he is done with all the 80 folders someone comes and tells him they had got the numbering wrong and all the numbers need to be changed. He shoots himself.

So to stop myself and others from being killed, I came up with a small (but effective solution). Automate this process. Usually we work off SAS. Doing this through SAS might have taken a little more time (which no one had) but like Michael suggested, I made it my night job. A simple application in C# would not take more than a few minutes to bring about the desired automation.

The next morning I did a small demo before my manager. He was happy. 3 hours of work had come down to 3 seconds. The programmers were happy. Everyone was happy. But most important - automation had taken its first tiny step. Suddenly I had people come up to me and say - "Hey, can this be automated too?" - "If we can write a generic program for this, it can save us a lot of time" etc. I find myself much more busy, but much more satisfied! The programmers are smiling. They finally got to go home early! A very small 20 line program can change the way everyone looks at automation today.

So when your workplace does not really support automation - look around. Definitely there is something which could be automated. There always is. Even the smallest thing. Once it gets noticed, there is no looking back.

On a different note - most people in the pharmaceutical industry might not know much about C# but to my surprise not a single person at work had heard about it! My manager just walked in today and wondered about this other issue and if it could be solved better with C#. For everyone at work, C# = Magic! ;-)

The Microsoft Interview - Revolutions

Interview 4:
I called up Ian after an hour and let him know I was down in the lobby. In a couple of minutes I found myself in his office. He said he was training someone on interviewing and wondered if it was OK with me to have him watch. No problemo! So now there were 3 of us. Ian started off with, "Lets write some code." Yay!! I was asked to write a program which was similiar to a mergesort. After writing it, I was asked to test it. While testing it, I was told to correct any errors I found. Writing code on a whiteboard is a whole new experience.

Advice 13: Practice writing code on paper or a whiteboard before your interview.

After finishing off with the above, I asked Ian how he would recommend testing some code like the one I had written. This led to a very interesting conversation where Ian walked me through a step by step process on how one would ideally test code and why certain things were done in certain ways etc. After this I was asked to test a program which would check for 2 rectangles overlapping. But I had to apply everything which Ian had taught me over the last 15 mins. Had I not paid good attention to what he was saying, I would have been in a fix! :-) I felt I did really well here.

We spoke general stuff about testing etc. and then Ian briefed me on how it would be to work at MS. If I was chosen for the group I was interviewing for, what my responsibilities would be, etc. By this time I started thinking I was almost hired which brings me to:

Advice 14: Read Advice 10 of Part 2.


Ian walked me to the lobby and asked me to wait for my next interviewer - Mike.

Interview 5:
Mike also happened to be a Test Manager and my last interview of the day. By this time I was close to being called a Zombie! I could have done with an energy bar which I had not carried. We started off initailly by talking about SDLC and the role of test. Then I was given a "simpler" puzzle and then a difficult one. I got the difficult one rather easily but took time on the simpler one. Heh! At this point Mike said he liked my thought process. Yes, yes, I was on Cloud No. 9. Then he got into the team player mode.

Mike: "I am a fellow tester who hates being disturbed or working as a team. As a matter of fact, the whole team might hate me, I dont care. You need information about a certain part of the project on which I am working. You might need my opinion, you might need my code. How will you approach me?"

My first thoughts were why hire such a person...? But I let those remain as thoughts. After talking generally about team relationships, my reply was a direct approach of walking to the person with a friendly hello, letting him know about the situation I was in and saying it would really help in taking this product dev/test process ahead if he could provide me with his invaluable guidance.

Mike: "Doesnt work for me. Leave me alone, get out of my room."

I assumed it was the fellow testers response and told him about various other approaches I might try. I got the same response to all of them.

Mike made me go through several such excercises and when I look back on them, I messed up in several of those. Some of my answers were actually "pathetic".

Finally Mike picked up his laptop, and asked me to test a certain feature on it. Apparently his desk was all filled with paperwork + desktops so I decided to keep the laptop on my lap (oh, now I know why they named it that!!). But Mike pulled up 2 cardboard boxes, put one on top of the other and said I should use them to place the laptop! After a while I was paying less attention to testing the feature and more attention to balancing the laptop on those boxes!

We finally spoke about trustworthy computing and some other areas where MS plans to grow. I was finally told the positions I was interviewing for. As Mike walked me to the lobby he asked if I planned to get a PhD. He said Building 19 was just across the street and I could walk it up. As I dragged a tired me across the street on a cold January evening, I knew deep inside that I had messed up the last interview. Only if Mike considered balancing his laptop a brilliant act, I might get this job.

Advice 15: Learn to balance laptops! Just kidding! But seriously, towards the end of the day, you will feel dead tired. But these interviews are probably the most important ones (what people call - as appropriate). Just think its now or never and give yourself one last push!

If you love writing code, solving puzzles etc. you wont be mentally drained out. As a matter of fact, even after 5 interviews I felt all pumped up. But my throat was killing me with all the chit-chatting I had done!

Amanda called me on the day she promised she would. "You came very close, it was a tough decision, but the groups you interviewed with have decided not to make you an offer." Oh well, it was a good excuse to go out drinking and drown your sorrows. A week later, Amanda calls while I am in the bus. Hmmm... maybe they made a mistake, maybe I actually got the job! "You came very close, it was a tough decision, but the groups you interviewed with have decided not to make you an offer." Errr... Amanda, you told me that last week. "oh I did, so sorry, I didnt note it down that I made the call. your file is still lying on my desk." Are you sure nothings changed in that file? We both laughed! Its okay... the bus stops right in front of the liquor store!

Advice 16: Know where the liquor store is.

The Microsoft Interview - Reloaded

In this post I would be changing the names of those who interviewed me. Also, I would be changing the order in which I was interviewed (probably you would know why I did this as you read on)

The journey:

Flying Newark to Seattle is a good 6 hour journey. It doesn't really help if you have a 2 year old kid seated behind you who insists on crying for those 6 hours. Everytime I saw a passenger take out his laptop I wondered if he was a MS employee and if he was writing some C# code? Ear plugs made life a little easier and after a while I found myself in a cab headed to the Courtyard Marriott in Bellevue. After paying off the cabbie I was wished Good Luck for my interview. Eh? How did he know??!! I reached the hotel by about 11 PM and a note in my room read "Microsoft and the Courtyard welcomes you". I plopped into my bed and woke up halfway into the night, still wondering how the cab driver knew I was here to interview. Maybe I should have asked him what kind of questions to expect in the interview. He might have known!

I spent the day before the interview just chilling around reading some stuff and went off to sleep early. Once again I found myself awake halfway into the night. No cab driver nightmares this time tho!

As I walked out by 7 AM, I saw the breakfast lobby flooded with would be MS employees! Aha! No wonder the cabbie knew! The ride to Building 19 was a fairly short one. The cab driver happened to be from India, so we managed to speak a couple of Hindi words with each other. By this time I was really nervous. The initial form that was given, I filled it out in the wrong manner. There were some 10 others waiting with me and one by one a recruiter would come, call out their names and take them to their office. This other candidate who apparently seemed more nervous than me tried to get out his nervousness by talking with everyone around him. He actually walked up to me and asked "Why Microsoft? Which position at Microsoft and why that position?" Fortunately Amanda, my recruiter came out and called my name. I was rescued!

Initial HR:
Amanda had a sweet office and asked me if I would like some coffee, how my journey had been etc etc. Then she went into the regular introductory questions, and told me which groups I would be interviewing with. At this point I made it clear to her that I had mailed my university recruiter a week before my interview asking which groups I would be interviewing with. At that point I was told that it would be decided on that very day since positions keep opening and closing. Hence, I had no clue as to what these 2 groups are working on. She said she was aware of that situation and would inform the people I would interview with that I had not been informed beforehand.

Advice 7: Try to find out the groups you would be interviewing with beforehand. You can research on this group and with a little more information, you might come out as an "ideal match".

Amanda interviewed me for a while, asked about my various projects, which one I found more interesting etc. At one point I also asked her if I am shown the door after 2 or 3 interviews, does it mean my performance was rock bottom. She said she has no sure answer for this. She knows candidates who were interviewed by 3 people in a loop and got a job and others who had 7 interviews and were rejected. Saying this, she took me out to the shuttle and I was on my way to Building 17 for my first interview in the loop.


Interview 1:
Betty came across as a very friendly person and met me in the lobby. As we walked up to her cabin, she tried to put me at ease by asking questions like would I like a drink, do I like Seattle, the typical chit-chat. All I knew was its a blatant attempt to make me feel comfortable before she starts her attack! I put in the first question which got us going - "What role do you play around here?" I was a little shocked when she said she was a STE! I was expecting a Lead or a Manager to interview me. Upon asking her how long she had been here, she said about 12 years or so. By this time I was all confused. 12 years and STE? Fortunately she clarified that she came in as a contractor, became permanent, went on to be a Lead and then a Manager, missed getting her hands dirty with code, so after lot of talks with the management, she finally got back to STE.

Betty and I got along really well. We spoke a lot about testing and being my first interview I asked almost as many questions as I might ask in a year. We got down to testing where she asked me to generate test cases for reversing a sentence a.k.a: "I am a coder" -> "Coder a am I". She asked me if I had heard of this one before and I told her that I had actually written code for this couple of days back. I think I did pretty well at this and we spoke about the different scenarios, categorized tests etc. After I felt I was done, she asked me one little question and it made all my tests null and void! It was like having a house built and then realising that all the occupants are 12 feet in height after its built! Fortunately I had asked clarifying questions in the start, but had missed out on this one. Hence I felt it was ok! It was really one of those "I would never think of it" scenarios. But then, thats what a good tester would think of!

Advice 8: Ask clarifying questions before you start coding or testing. Think a lot before you say anything. Even if you know the solution beforehand - THINK!!

There was a point when I asked Betty few questions and she said these were the exact questions she was about to ask me. Finally she wanted me to write some code, but said we were short on time. So said she would simply ask me if I knew how to write code. Now it would look stupid if I took time to think on this one, so I immediately answered in the positive and she took me to the lobby for my next interviewer.

By this time my initial nerves were gone. I was enjoying what I was going through and my perception about the people working at MS had completely changed. This did not last for too long.

Interview 2:
Mark met me in the lobby and said that I was late. Apparently Betty had taken too long and now he did not have enough time. Ok... not really my fault. And Betty probably took 10 mins more than the alotted one hour. Did it really matter? Ok, maybe Mark had some meetings to attend. Anyways, when we got into his office his phone rang. This is his end of the conversation. "No, you know I dont do that." "No Betty, asking code is not my cup of tea. Bye." Here I was dying to write code, and the first 2 interviews were gonna go by without any coding!

Anyways, Mark got into a lot of management related questions. Actually we started talking about marketting after a while. On how I would sell the product to my customer. Is it better to call them at certain centres to give a demo or should you ship CD's with the product to people interested during the beta stage etc. etc. After a while I was wondering what position I was interviewing for. Personally I felt my answers were "OK" but there was one part which disturbed me. Everytime I start to talk, Mark looked at his watch. Everytime I take time to think of something, he says I have to be quick since I didnt have time. Initially I was confused and at the same time not thinking to my best. Frankly, I was not too comfortable with Mark's way of interviewing. But then I thought maybe it is part of the interview and he is trying to stress me out. I maintained my stance of "thinking before answering" and he repeatedly kept saying we are short of time. We did not talk about code, we did not talk about testing. We just argued about management aspects & marketting. A little about my projects and places where I felt I could have done better.

Advice 9: Even if you are applying for a design/test position, brush up on the basics of management/marketting/anything vaguely related. You could get general questions which will touch the basics of all aspects of software development.

So finally Mark said his time was up and if I had any questions I should ask while we walked to the next interviewers cabin.

Interview 3:
Mark took me to the office of Ahmed, introduced me, spoke to Ahmed for a couple of minutes and left. Ahmed came up to me, introduced himself and said I was early. Probably half an hour before schedule and wondered if I could wait in the lobby for a while. One person says I am late, the other person says I am early. By this time I was wondering if this was Microsoft? So I found myself waiting in the lobby, pretty sure Mark is typing a "No Hire" for me. Ahmed turned up after half an hour and said we should go grab some lunch. Great! He suggested we head for an Indian restaurant.

Advice 10: Dont second guess how your interview went.

Ahmed turned out to be a very friendly person and once again my opinion about the people working at Microsoft changed. He was a Test Lead and knew which restaurant makes good Indian food! He initially spoke a lot about himself and how his wife insists they should eat at the Indian restaurant at least once a week! While driving he asked me, "If I ask you to test something, what will you do?" Very open ended question. So I naturally asked him, "I will ask you what you want me to test." After that I spent almost one good hour figuring out how to test a calculator. I was asked to generate bug reports, test plans etc. A lot of thought went into developer/tester relationships. I think I did pretty well on this one. But still, no code! I was almost going to beg him to ask me to write some code when (miracle!!) he asked to write code (yay!). Generate all numbers which are multiples of 8, less than 80. I thought this is too simple, there has to be a catch in it somewhere... so I started thinking of all the possibilities where I could go wrong. Can you believe it, I asked clarifying questions in this scenario too!!!! Finally Ahmed assured me there was no trick in this, he just wanted to see my coding style.

Advice 11: Read the .net design guidelines.


We drove back to Ahmeds office where he gave me a name and a phone number and asked me to call that number after an hour. The person was a Test Manager and that would be my next interview. So I spent one hour after lunch sitting in the lobby. All the waiting was making me tired and drowsy. I could partly blame it on the Indian food.

Advice 12: Eat well, but eat light. Try carrying an energy bar with you. Eating small amounts between interviews is an excellent way to keep your energy level up. Also, carry a bottle of water with you. A lot of talking, standing and walking could make you dehydrated. Oh... and waiting too!

Wanna know if I made it further?

Part 3

The Microsoft Interview - Part 1

I had interviewed with MS more than a year ago but did not blog about the experience since I thought its not ethical to do so. I was surprised to see JobsBlog ask for links to Microsoft interview experiences. So I thought, heck, if Gretchen is asking for it, why not do it!! And while I am at it, lemme throw in some free advice.

Note: I still dont find it ethical to give out questions that were asked. Altho I shall give out a few of them (which already exist if you Google for "Microsoft Interview Questions")

Lets start off right from square one.


Advice 1: Dont give up on applying. I changed the format/wording of my resume many a time and kept updating it with new projects/technologies I was working on. When you strike the right balance, you will get noticed.

- I had applied to MS sometime in Jan 2002 (for an internship) during our career fair. Not that I had stellar programming skills then, but MS was the only worthwhile company which came on campus. Then I applied again. Online. Then again I applied when they were visiting Syracuse in Oct 2002 or so. One fine day I got an e-mail from a MS recruiter where I had to answer some questions she had sent as an attachment. Didnt hear anything from her after that and I was asked to be patient. :-) Once again, they were in SU in Jan 2003 and once again I applied. Still no response. Mid 2003 I graduated and was training with a company in NJ (read: Working for free) when I got an e-mail asking if I was ready to interview with MS at the Syracuse campus.

- Oct 2003, I found myself interviewing for the SDET position. This was the first time I was ever interviewing in my life so I was all nerves. This was a half an hour interview at the SU campus. And I felt this interview was brilliant. I was interviewed by Navi Ahmed who was a Test Manager in the Windows CE group. Very friendly person who laughed at almost everything. He started off with regular questions as to why testing, why MS, spoke about one of my projects, discussed some OOD principles, asked me a coding question and then a logic question. Finally I was asked if I had any questions.

Advice 2: Be methodical in your approach. Talk out loud and clear. Even if you are stuck with a problem, talk about all the possible ways you are thinking of getting to the solution (even if they end up being not quite right). Also, if you are being tested in an area you are not comfortable with, make it clear. They would rather test you on your strengths. (Note: This does not mean you can show all your experience in C++ and when asked questions in C++, say you are not comfortable with it! But if you have limited experience in MFC and your interviewer goes into details of MFC, let him know you aint a pro!!)

- When I look back on my interview, few things stand out in my mind. My answers to certain parts of these questions were wrong. The logic part, I got it right, but it was not the best way to solve the question. I confused overloading with over-riding. Lots of disasters. What I noticed is I considered many options (including the right one) before I chose the wrong one. Where I rocked was the way I wrote code and the way I tested it. I was very methodical, clear and verbose in my explanations.

- Fortunately I asked Navi by when I would expect the results and if I dont hear from MS who should I get in touch with? I was given a timeline of 2-3 weeks and if I did not hear from MS, to get in touch with my college recruiter. The way the interview went, I came out thinking it was all over and I am definitely not flying to Redmond anytime soon.

Advice 3: Dont try to guess how well you fared.

- Almost a month went by and I had not heard of anything from MS. I thought they probably dont care about sending out rejections, but nevertheless, I mailed Lisa who was the college recruiter for SU. I got a quick reply from her saying she would check into the issue and let me know. After a week, I got a mail from Lisa that I was flying to Redmond to interview for a STE. There was some problem with the paperwork and the results had not reached her. She might have never noticed this had I not mailed her and asked.

Advice 4: Always follow up. Not only does it show your interest in the position, but it could actually get you a step closer to the job.

- STE??? I had applied for SDET (my second option was STE). But then, I had heard that MS fits you into the role they think you are best suited for. Probably they thought I was a better fit for STE rather than a SDET!

Advice 5: If you are inclined towards a particular position, dont compromise on it.

- Lisa's mail particularly said that someone from MS would get in touch with me regarding my travel schedule. About 10 days pass and I have no mail. So once again I got back to Lisa, asking if it usually takes this amount of time or is there some problem. Once again Lisa said she would look into it and the very next day I got a mail asking me about my travel plans. I was flying to Redmond and interviewing on 26th Jan 2004.

Advice 6: Once again, if anything you feel is wrong, get in touch with your assigned recruiter. They are highly friendly and helpful!

If you got so far, you probably wanna click the link below.

Part - II