09-03-2008 02:16 PM - edited 09-03-2008 02:29 PM
This is crossposted from BlackBerryForums, I thought that it was best to get the information closer to RIM. There are well known memory and stability issues, so I won't report those. Instead, I'll report some less obvious "nitpicks" plus "usability issues" -- as I want RIM to successfully compete with iPhone. (People know me to be a big BlackBerry fan, but I am also a balanced software developer who also programs for Windows Mobile, BlackBerry, and iPhone -- so I have knowledge on several major smartphone platforms, making me qualified to comment on improvements). I also used to maintain a very old BlackBerry FAQ (back in year 2005) at www.berryfaq.com -- although that link is now out of date.
Moderators, please feel free to forward a link to this post to other RIM insiders who would be interested in monitoring my comments.
Now, my slightly-edited crosspost from BlackBerryForums:
Mark Rejhon's BlackBerry Bold Bug Reports
Updated August 26th, 2008
BlackBerryOS: Rogers Apps Version 18.104.22.168
Device: BlackBerry Bold
First, the BlackBerry Bold is the best BlackBerry I've owned. Congratulations on such a refined BlackBerry unit that can only improve further with software updates. Many things about it is great, especially the greatly improved fonts.
However, I'm creating this thread to keep track of Bold bugs/issues/shortcomings I've discovered that I feel worth writing about. Hopefully RIM employees reads this thread, and implements these fixes in future OS's.
BlackBerry Bold Browser
General Consistency Issues
I also observe hundreds of users on HowardForums.com switching back and fourth between BlackBerry and iPhone, so such a consistency 'nitpick' is fairgame to RIM for whatever cost-benefit analysis they do, with their obvious recent iPhone-chasing behaviour -- there's a lot more agreement here to these little kinds of nitpicks than you think, especially among the non-platform-partisan crowd. (Apple users are a very nitpicky bunch, you see -- while some of them really like the BlackBerry Bold, as evidenced by the dozens of forum posts over there, even in the Rogers section -- although I am platform-neutral myself)
There are plenty more bugs/issues/shortcomings, some too minor for me to remember to report here, I'll update this thread as time goes, so maybe copy and paste the URL to whatever bugtracking system you use within RIM internally.
09-03-2008 02:18 PM - edited 09-03-2008 02:25 PM
Another post of mine from BlackBerryForums.com:
RIM Needs to Consider Better Web Browser
There's a ZDNet article that suggests that many mobile companies should use superior web browsers, and also complains about BlackBerry Bold's slow web browser.
There are strong rumors that RIM is already doing WebKit for the first touchscreen BlackBerry. Hopefully this is true -- if so -- congratulations, RIM made an excellent choice. We can thus expect a much better revisions of BlackBerry Bold browser to arrive.
-> In addition, better zooming is a MUST in the browser. See my suggestions in my previous post about better zooming consistency.
-> Improve smoothness of rendering, especially offscreen portions of web browser. iPhone does a great job of using checkerboard placeholder for unrendered parts of a webpage, while allowing you to smooth scroll.
-> Minor item: Consider optional 'flick scroll' animation for the web browser: Flick the trackball fast and it slide-scrolls like an iPhone. The new version of Google GMAIL Mobile for BlackBerry does this; it's wonderfully implemented -- RIM should download this and add an Options->Screen/Keyboard->Scrolling Animation->Enable on by default so that all lists can do nice "flick scrolling", while letting people who hate animations still be able to turn it off. In fact, it. This should be placed everywhere scrolling animation can be useful - including the Home screen. Some of us love this animation and makes it easier to use the BlackBerry, as long as the animation is fast (like iPhone), it's interesting that a third-party Google BlackBerry app does scrolling much better than BlackBerry's Messages Inbox!
09-03-2008 02:19 PM - edited 09-03-2008 02:26 PM
Yet another post of mine from BlackBerryForums.com:
Possible Developer Improvements for BlackBerry
- Add a BlackBerry "AppStore", to compete with Apple. Does not need to keep applications exclusive to the AppStore (people can keep downloading apps independently), but by the virtue of super-easy AppStore being pre-installed on BlackBerries, developers will find it very irresistible to add their own applications to this AppStore. This would be enabled by default because RIM's market is becoming consumer by majority soon or already (i.e. we're approaching or passing more than 50% of BlackBerries being sold to individual consumers rather than businesses), the AppStore becomes more important. For businesses, there could be a BES policy that can turn it off for corporations/goverments. Carriers who dislike AppStore can turn it off too, until peer pressure from users can turn AppStore back on. Yes, there's competing options of application stores already for BlackBerry by third parties, but these are often vendor specific. There needs to be a unified AppStore: Many people don't realize there's 10 different brands of chat software available for BlackBerry, as well as at least 6 different brands of GPS navigation software, as an example! New users of BlackBerry think there's nothing for BlackBerry, because it's so hard to find BlackBerry software.
- Provide better and easier to search development documentation than javadocs format. Javadocs is nice and could be kept in parallel, however, part of the RIM $150 million development fund should be spent on a separate team for improved online developer documentation and improved API's that's easier to search, cross-reference, direct links to source code samples, etc. This could be a separate team competing in parallel to the javadocs team, for the evolution of who can do it the best (two teams racing to produce better development documentation), as many people still demand to keep the javadocs format -- And the help for a specific API call should be more integrated into JDE, even with pop-up balloon tips. RIM JDE is kind of getting long in the tooth -- it was pretty modern looking five years ago, but JDE is almost exactly the same looking as it was in 2003 or 2004. Some good ideas can be obtained from other software such as Apple's XCode, Microsoft's Visual Studio 2008, or even better Java development environments such as Eclipse.
- Add better API's that makes current and future BlackBerry development easier. For example, it would be nice if software such as Rove Mobile Desktop (VNC/Remote Desktop) could use the BlackBerry Browser's mouse cursor, it has very nice and smooth acceleration.
- Optimize the Java environment to have near top performance numbers at JBenchmark and other Java benchmarks. This may take two or three years, since RIM has to plan future chipsets, design new BlackBerries, and optimize for them. BlackBerry has improved greatly in performance, but still could be even better. Many Nokia have Java that seems to run 10 times faster than BlackBerry does, for example.
- Optionally (this may not be easy, although Apple has pulled off wildly successful platform switches in the past -- 68K->PowerPC->Intel) by the beginning of next decade (2010+), in the longer term, consider opening also be able to do C++ development to allow high performance software such as 3D videogames. Java is great but it is extremely hard to program things such as 3D videogames at good performance levels, as an example. If the Java environment can't be optimized to compete with iPhone 3D performance levels, then maybe the entire Java environment can be kept, but perhaps running on top of a UNIX-like infrastructure, with the option to produce native ARM executables. Basically, give developers the choice to do either Java code and native C++ code. Security implications of doing this switch would exist (BlackBerries are widely known to be very secure devices), so RIM needs to weigh the benefit of doing this, versus staying Java-only. If RIM hasn't already started planning or considering a cost-benefit analysis of a major "development environment" switch, one should be done immediately -- there's still time before other manufacturers (i.e. Apple) get too far ahead.
- RIM is probably already working on this since many smartphone vendors are slowly going in this direction: Add high quality 2D/3D acceleration support into BlackBerries. (Bold may already have 2D acceleration support, as animations on it perform much more smoothly than previous BlackBerries) This will also improve benchmarks and ability to do things such as 3D stuff in the long term. Many phones such as Nokia and iPhone, already has this already. While BlackBerry has now added hardware video decoding and good video scaling (for H.264 playback, etc), better acceleration for 2D/3D is needed, to compete in the consumer phone territory. 2D and 3D support are also useful for animations and screen transitions (like on iPhone and other recent touchscreen devices; so to compete with these touchscreen devices). Pinch-zoom, for example, needs high-framerate scaling of images, often using the acceleration support. The animations during flipping between screens, like smooth zooming or flipping, often utilizes 2D/3D support too. For slicker UI operation, the use of 2D/3D support is useful, as long as it does not sacrifice significant battery power.
- Add more API's for visual enhancements to BlackBerry applications for developers. Make it super-easy for even a beginner developer to make a slick-looking application. Examples include exposure to API's that does smooth scrolling animations automatically with acceleration/deceleration support. For example, GMAIL Mobile has wonderful scrolling (they copied a scrolling algorithm similiar to iPhone to BlackBerry, to allow flick-scrolling on the trackball), better than BlackBerry email, it almost feels like iPhone scrolling (flick-scroll on the trackball). Take a look at this, and consider adding API's that allow third party developers to take advantage of such things, or even build-it-in to the standard RIM controls, and allow the ability to turn this on/off via Options.
Most people think I would be nitpicking, of course -- but I think many BlackBerry developers who also know Apple XCode, are shocked how primitive and difficult the RIM development environment still is, in comparision. Yes, it keeps the incomes of many BlackBerry developers high due to its difficulty, but...