Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

BlackBerry® Bold™

Reply
Developer
Posts: 19
Registered: ‎06-20-2008
My Device: Not Specified

[BIG POST] Suggestions for RIM - BugZilla - regarding BlackBerry Bold and future devices

[ Edited ]

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:

______________

 

Hello,

Mark Rejhon's BlackBerry Bold Bug Reports

Updated August 26th, 2008
BlackBerryOS: Rogers Apps Version 4.6.0.125
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

  • Further improvement to zoom is necessary: When I zoom, I'd like the zoom to automatically center itself at the mouse cursor (magnifying glass) much like in Opera Mini. Basically mouse cursor stays in exactly the same part of the webpage, i.e. hovering over the same word or same corner of image. Basically if I move my magnifying glass to specific text in the middle of the page, I'd like the center of the zoom to be where the mouse cursor is. Also, repeated tapping of "i" and "o" should stay exactly in the same place rather than shift all over the webpage. (If necessary, move the mouse cursor to stay in exactly the same part of the page)
  • There is an error message rendering the desktop version of Google News
    news. google. com?noredir=true
    (Also reached at Google, click "Classic" instead of Mobile, then click "News")
  • My personal website is viewable, but there are some frameset bugs rendering www .marky .com ... It is a very old web design (over 10 years old!) but should be a good test of fixing frameset support in the next browser update.

 

Picture Viewer

  • I can no longer zoom in/out of images using "i" and "o" key like I used to be able to on BlackBerry Curve (4.2). This is inconsistent: "i" and "o" zooming works on BlackBerry Bold in Browser (but not Image viewing), while works on BlackBerry Curve in image viewing (but not browser). Also, it would be nice to have the same zooming behaviour in attachment viewing. RIM, please be consistent with zoom keypress shortcuts. It is very important to be "Apple-consistent" in many areas if trying to complete with the iPhone. That includes keypress shortcuts that have been removed from the image viewer. (The letter i and o keys for zooming is perfect because it means "In" and "Out", and are adjacent keys on most keyboards).
    Resolution: Please include a mention of zoom keypress shortcut consistency in whatever UI Design Standard you use company wide.
    Suggestion #2: Additionally, it would be nice to have a consistent method of a modifier key and spin the trackball up/down to zoom in/out in both Bold's Browser and Picture Viewer.

 

Attachment Viewer

  • Fax file attachments look very ugly in GIF format, especially since the thumbnail appears to be scaled 150% (point sampled -- ugly pixellation -- rather than bilinear/bicubic interplation).
  • When I am viewing an email with multiple GIF attachments (fax pages) or JPEG photo attachments, then I view each page one by one, then I go back to the email, it becomes very hard to select image #3 out of 5 image file attachments in one email message. This is because scrolling through the original email becomes very jumpy when all 5 images show up inline. The scrolling-through and selecting of image attachments should be improved to be less jumpy, and scroll as smoothly as scrolling through the text portion of the email message.
  • Zooming behaviour is inconsistent with other zoomable stuff in the BlackBerry (images, browser). I can't use "i" and "o" keys.

 

Options

  • Screen/Keyboard has a minimum font size of 7 points. That's excessively big, considering BlackBerry Bold's new fonts are readable even down to 1 point or 2 point size (as shown in Bold Browser if you have good eyes) with the excellent antialiasing and the ultra high resolution 224dpi LCD screen. I have found that 5 point font on Bold is more readable than 7 point font on a Curve.
    Resolution: Modify "Screen/Keyboard"->"Font Size" to have a smaller minimum such as 4 or 5 point.
  • I want to be able to adjust backlight down to 1% for use in darkened rooms such as the bedroom without disturbing the better half, for night sight preservation during camping, and theater rooms (for discreet quick glances at email list). The Bold backlight is obviously capable of this (just go into bedside mode, the backlight automatically dims to 1% brightness once it is in bedside mode in a dark room).
    Resolution: Modify "Screen/Keyboard"->"Backlight Brightness" to have a "1%" and "5%" setting alongside the "10%" through "100%" settings.

 

General Consistency Issues

 

  • Zoom In/Out Inconsistency - Not consistent in everything that's zoomable

    Areas that "i" / "o" zooming keypress shortcuts works:

    ...BlackBerry Maps
    ...BlackBerry Browser
    ...Google Maps
    ...Formerly Picture Viewer (Curve 4.2)

    Areas that "i" / "o" zooming keypress shortcuts doesn't work:
    ...Attachment Viewing of images
    ...Picture Viewer (Bold 4.6.0.125)

    To improve user friendliness of zooming, because iPhone has such wonderful pinch-zoom and won't be matched until Thunder (and since not all BlackBerries are planned to be touchscreen in future, anyway) - make sure that zooming behaviour is as consistent as possible across all applications. Maybe to extend things further, when holding down a modifier key, a corner of screen could show a transparent [ZOOM 115% ||||||||---------] bargraph/counter at which point spinning the ball will zoom in/out smoothly in real-time until the trackball stops spinning or the ball is clicked. (Note, this transparent corner popup could auto-appear too when pressing the "z", "i" or "o" keys, to automatically enable the trackball to also control zooming too -- and the popup can autodissappear)

    Possible suggested use cases:
    User clicks "i" -- zooms in by 1 step and autoshows the zoom bar
    User clicks "o" -- zooms out by 1 step and autoshows the zoom bar
    User clicks "z" -- autoshows the zoom bar
    User brings up menu and selects "Zoom", this autoshows the zoom bar
    User spins trackball while zoom bar is shown; zooms in/out.
    User holds ALT, zoom bar autoshows (for ALT+trackwheel zooming)
    Zoom bar autohides after X seconds (say, 2 or 5 sec) if no keys/trackball touched
    Clicking trackball or hitting Enter will immediately autohide zoom bar

    Or for screens that aren't well-represented by a zoom bar, use a zoom counter instead (like a black translucent rectangle in a corner with white text simply saying "Zoom 75%"). Currently, it's not easy to figure out where the 100% zoom level is for images, because it's not clearly marked - sometimes I like to view images on a pixel-for-pixel basis.

    (By all means, RIM is free to come up with something better for non-touchscreen BlackBerries. And please include zooming consistency behaviour in whatever UI Guidelines you use internally for BlackBerry UI design.)

 

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.

Message Edited by mdrejhon on 09-03-2008 02:17 PM
Message Edited by mdrejhon on 09-03-2008 02:27 PM
Message Edited by mdrejhon on 09-03-2008 02:28 PM
Message Edited by mdrejhon on 09-03-2008 02:29 PM
Developer
Posts: 19
Registered: ‎06-20-2008
My Device: Not Specified

Re: [BIG POST] Suggestions for RIM - BugZilla - regarding BlackBerry Bold and future devices

[ Edited ]

Another post of mine from BlackBerryForums.com:
__________________

 

 

RIM Needs to Consider Better Web Browser

Consider WebKit & V8 JavaScript
RIM also needs to consider sourcing a third-party web browser engine such as WebKit, and perhaps use Google's amazingly fast V8 JavaScript engine, in the recently launched Chrome browser, which will also be reused in the Google Android project. It's all well and okay to try to continue an in-house browser engine, but the open source options are so clearly superior and far ahead (FireFox 3.1 and Safari's 'WebKit' engine), and there's ways to include this open source option safely alongside the BlackBerry stuff.

 

The V8 open source ultra-fast JavaScript engine is open source and used in Google Chrome.  Check out Google Chrome (also for developers, see Google's Chrome Web Browser 'the-making-of' comic strip), there's a story where Google Chrome used software from their Android project, because it was the fastest out there.  WebKit based browser engine and V8 JavaScript engine.   Google's V8 JavaScript engine outperformed Safari, FireFox 3.0, etc...  And all of this is released into open source, so worthy of RIM's consideration as blogs suggest that RIM is already rumored to be working on WebKit.

 

The JavaScript engine is superior to Apple Safari's used on the iPhone, and runs twice as fast -- very useful on 624 Mhz ARM CPU's found on high end mobile devices. Fast for mobile, but slow for desktop-style web browsing. By using WebKit and V8 JavaScript. the BlackBerry Bold web browser could become equal to iPhone, and would be useful for Thunder/Storm/Javelin, all of which have CPU's fast enough for iPhone-quality web browsing.

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.

It is strongly encouraged that RIM finds a ultra-high-quality open source JavaScript engine to be coupled with the RIM WebKit based web browser. RIM should hurry up and immediately GRAB the Google V8 world's fastest JavaScript engine and plugs it into RIM's own WebKit powered web browser (Google is ACTUALLY encouraging it -- they're asking everyone to take the V8 source code -- so RIM should take it too.)

-> In addition, better zooming is a MUST in the browser. See my suggestions in my previous post about better zooming consistency.
-> Improve multithreading. Slow JavaScript should not grind the BlackBerry to a halt, one should still be able to scroll the page.
-> 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!

Message Edited by mdrejhon on 09-03-2008 02:25 PM
Message Edited by mdrejhon on 09-03-2008 02:25 PM
Developer
Posts: 19
Registered: ‎06-20-2008
My Device: Not Specified

Re: [BIG POST] Suggestions for RIM - BugZilla - regarding BlackBerry Bold and future devices

[ Edited ]

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...

Message Edited by mdrejhon on 09-03-2008 02:26 PM