The user can be a visitor to a website, a member of a website with more access, or even the website administrators. A user can be anyone who interacts with the piece of software in any way. Similar to use cases, the ultimate purpose of user stories is to collect and understand requirements. The difference is that user stories are meant to be easy to read while sparing the detailed descriptions of the steps that it entails. In this way, a client describing the functionality that they want can be understood without the need for a technical background. This is advantageous in many ways, and not only in communication between the provider and the client. An example of a user stories could be as follows:

• As a user, I will be able to authenticate and uniquely identify myself to the website by using a username and password so that I can use other parts of the site.
• As an authenticated user, I want to be able to see what is on the menu, so I know what is available for me to order.

User stories are frequently used in software development firms that make use of agile methodologies such as XP or SCRUM, like AndPlus Design. This is beneficial because a product backlog is much simpler to develop if we already have the user stories. From the product backlog, features can be broken down into sprints (or milestones, depending on methodology), which help ensure smooth development and accurate estimates.

The “Loop” is nothing special as any other smartphone would also have the ability to stay connected too. The Kin Studio can cause problems, as Microsoft has already messed up once during the major SideKick data loss fiasco not long ago. The phones are small and lacking in technical features and power. With all this, you would think maybe it’d be worth it if it was cheaper than the cost of a plan for a regular smartphone, but it actually costs the same. So you’re paying the same amount for less.. not good.

The biggest problem is that this was just too little, too late. If Microsoft had been able to get the Kin project out there long before the iPhone, Android, or Blackberry devices, maybe it would have succeeded. If someone tried to build a new Facebook right now, they’d also be in trouble. The market has just already been taken over for too long, and the competing product would need years of development in order to catch up to the existing competition. You want to keep your product fresh, up to date, and ahead of the competition, and that was where Microsoft went wrong.

For example, when creating a new file, we might first check if it exists, and if it does, if it is writeable.  Then if it is not, we check if the parent directory is writeable.  Finally, check if the disk has free disk space.  This seems like a pretty valid approach at first glance but a million things can go wrong.  What if you’re on a UNIX system, and the directory is mounted to a different partition than the central one?  Now your code to check disk space has grown more complicated.  But still, this can work, right?  Well it could still be an invalid file system.  What if it’s valid on one file system but not on another?  You could have a vast library of code to verify filenames on different platforms, but as soon as one platform starts allowing more generic filenames, your code is overly restrictive.

So, trying to verify that you can create a file before creating it leads to a large library of code to a solution that mostly works.  And of course if a process changes directory permissions between verifying that you can create a file and creating the file, your program will still crash.  A solution that works 90% of the time and possibly annoys users is possible in this manner with a lot of effort, but obviously not advisable.  Then, there is the other solution:  try and apologize.  Whatever language you are running has some manner of exceptions or failure codes.  Try to open the file, and if there is an exception (or an invalid return code), display the error to the user.  One simple solution, cross platform, future proof, and beautiful.

This idea of trying an action and diagnosing any errors resulting leads to an important corollary: check results not side-effects.  I had to write an installation manager for a suite of software, which ran actual installers as subprocesses.  I spent hours attempting to verify return codes, parsing logs, and even timing the installers.  Logs ended up being different in different versions of windows, timing was unreliable at best, and return codes were completely useless.  In the end, I realized the best solution was staring me in the face.  Wait for the installer to exit, and check the registry to see if the software was installed.  If it was, then obviously the installer succeeded.

When writing software, just do what you want to do, and deal with the problems that arise.  When verifying actions, check for the expected results, not whether or not the actions think they succeeded.  These two simple rules will save you many headaches.

After searching more on multiple search engines, I found a more relevant site to use; http://www.prelovac.com/vladimir/top-list-of-social-media-sites .

I consider myself somewhat of a social media expert. But, mainly only for these four popular social media networking sites, Facebook, MySpace, Linked-In, and Twitter. I want to learn more about the sites that I am not so familiar with. I have decided to take 5 sites and learn a little more about them, mainly by signing up and seeing what happens and if they are beneficial.

The sites I decided to try are:

• Plaxo
• Biznik
• FastPitch
• Merchant Circles
• Digg

Signing up for these sites took around ten minutes each. I have learned through some research that Advanced Search is a very important tool to use. Before you sign up to any site, make sure you know who your target audience is.

So, I have signed up for all 5 sites and am still not convinced they are as effective as I had hoped. I feel it is hard to join new sites when you have no connections on the site at all. I have decided to wait it out for 30 days and see what the results will be…

How will I grow my connections? How will I get my company’s name out through the site? Most importantly, how do I get potential leads to my company’s website?

Hopefully, answers will follow! To be continued…

At AndPlus Design, we do things a little differently.  While keeping developer’s source code in source control is standard policy almost everywhere, servers are another matter entirely.  This is a sad state of affairs, because there’s really no reason not to.  Disk space is a commodity, much cheaper than time, and reliable source control solutions like Subversion have no issues storing large numbers of large files.  So, why not mirror a server’s web directory in source control, a live version, along with all of the development versions.  Even more commonly neglected than a server’s file system are the server’s data records.  So why not back these up in source control too.

Now if a server’s security is breached and data is modified, or if a user accidentally deletes their account, or even if a server suffers a fatal crash, we can look at previous versions of files and data, in exactly the same we would view changes between development versions of software.  And of course, if something breaks on a website, we can pinpoint when it changed and what caused it.

Based upon the principles above, AndPlusDesign has an automated backup solution which can easily handle an arbitrary number of websites and servers.  Every website’s files and databases are stored in source control daily.  Then, source control itself is backed up to multiple locations.  This is all implemented as a small set of python scripts.  Of course, nothing is a simple as it looks, and in Part II we will go over actual implementation strategies, gotchas, and solutions.

It only follows that companies should be expecting an increasing amount of visitors to be viewing their websites with mobile devices. Many websites with high traffic have already coded their sites so that they appear simpler and easier to use on mobile devices, especially iPhones and iPads. Some websites have specific HTML and CSS coded so that their appearance is different when viewed in portrait or landscape.

Additionally, many mobile devices do not support Adobe Flash. While some companies may rely on flash for their website interface, HTML5 is an alternative that is gaining rapid popularity. Today, even JavaScript can emulate much of the functionality of Flash. If you are using a service like Google Analytics, it is easy enough to find out how often visitors are viewing your website on a mobile platform by checking to see which browser platforms your visitors are using.

It is important to keep in mind the nature of mobile visitors. People often use mobile browsing for the purpose of finding information quickly, and they expect that the websites they visit cater to that purpose. If it is difficult to navigate your website on a mobile device, it is likely that the user will go back to Google and look for information (or services) elsewhere.

HTML5 will bring exciting new features such as a canvas for scripting drawings, images, and animation, audio and video support, and client-side database storage. Some Flash may be replaced by HTML5, as it could eliminate the need for third-party plugins such as Adobe Flash Player and Microsoft Silverlight for video-playback, and maybe even for some Flash games. Although HTML5 won’t even read W3C Recommendation for over another decade from now, browsers are already beginning to support many of the HTML5 draft features. None are fully compliant yet, but hopefully we won’t have to wait until 2022 to see a new web. One final note, not surprisingly, Microsoft Internet Explorer 9 is the farthest behind out of the top 5 Windows and Mac browsers.

A common theme to consider when created new websites, or even products, is the “Don’t Make Me Think” methodology, which was coined by Steve Krug in his book with the same title. Visitors are bombarded with much more information on the web now more than ever, and it can be difficult to browse websites with hundreds or even dozens of pages. Websites need to be created with simplicity and straightforwardness in order to be easy to navigate, so that visitors do not need to go digging for content. If a visitor cannot find the content that they are looking for on your website, they will likely go back to Google and find the content on a competitor’s website. Poor usability means lost business and frustrated visitors, as well as poor reviews of your site. Indeed, you may likely lose sales due to usability issues.

When creating the theme or content layout of a website, focus should be placed on what a completely new visitor will see when he or she visits your website. Pretend that the visitor has no prior knowledge of the site whatsoever. Information such as who you are, what you do, and what specific services you provide must be accesible from within one click of the home page. Eye tracking studies have revealed what visitors look at first when they see a web page, as well as how they scan a webpage and how long they focus their attention on headings, links, text, or images. If your site uses advertisements or sponsors, placement on the page is an important consideration. For example, users are accustomed to navigation panels placed on either the upper left or top center of a page. Advertisements are normally on the right side or bottom of a page. If you place your navigation links on the right side of your website, many visitors may not even see your navigation links, as they have already conditioned themselves to ignore that part of a website.

Dear Google Apps admin,

In order to continue to improve our products and deliver more sophisticated features and performance, we are harnessing some of the latest improvements in web browser technology.  This includes faster JavaScript processing and new standards like HTML5.  As a result, over the course of 2010, we will be phasing out support for Microsoft Internet Explorer 6.0 as well as other older browsers that are not supported by their own manufacturers.

We plan to begin phasing out support of these older browsers on the Google Docs suite and the Google Sites editor on March 1, 2010.  After that point, certain functionality within these applications may have higher latency and may not work correctly in these older browsers. Later in 2010, we will start to phase out support for these browsers for Google Mail and Google Calendar.

Google Apps will continue to support Internet Explorer 7.0 and above, Firefox 3.0 and above, Google Chrome 4.0 and above, and Safari 3.0 and above.

Starting this week, users on these older browsers will see a message in Google Docs and the Google Sites editor explaining this change and asking them to upgrade their browser.  We will also alert you again closer to March 1 to remind you of this change.

In 2009, the Google Apps team delivered more than 100 improvements to enhance your product experience.  We are aiming to beat that in 2010 and continue to deliver the best and most innovative collaboration products for businesses.

Thank you for your continued support!

Sincerely,

The Google Apps team

Email preferences: You have received this mandatory email service announcement to update you about important changes to your Google Apps product or account.

Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043