While all of you pay a nice flat rate of $20/month, we annoyingly have to pay a per MB rate to our carrier partner. What does this mean? The more services we offer, the more we pay. But fear not, we have a goal of not making you guys pay more than $20/month no matter what we do.. in fact if we could we’d reduce price! Hence my post about compression, compression is super duper important to us.
So we are hoping that some of you could think about how you use your Peek and how we could send less data.
I’ll start with one idea to get the ball rolling.
Many emails might be ‘low value’ emails. Things like newsletters or updates from fresh direct, etc. We could try to recognize some of these low value emails and if we did recognize them we could not send the email body unless you explicity open the email.
How many of you receive a high volumes of said ‘low value’ emails? Do you think this idea is possible, or would the experience of the lag of waiting to get the body be terrible?
I’d love to hear your thoughts about this idea, and any other zany ideas you have to help us out!
Opie | 04-Dec-08 at 3:03 am | Permalink
What is the latency of the cell network? Is there any reason why you couldn’t pull down the first Xkb of the email content only after the users selects to open the message? That way the only data that hits the device is the headers.
Derrick | 04-Dec-08 at 6:53 am | Permalink
I recieve a lot of low value emails.
DougK | 04-Dec-08 at 7:18 am | Permalink
I agree with Opie, sending just the headers would be a good way to go. I can usually tell from the subject line if it’s something I need to read now or if it can wait until I’m at my computer.
Allen | 04-Dec-08 at 7:27 am | Permalink
I can usually tell by the subject line if I need to open or not. But I also like the idea that the first bit of the email (maybe enough for the first line or so) can be opened. Then if the full email is needed, it can be called.
Mark B | 04-Dec-08 at 7:29 am | Permalink
Dan – when images are sent, are they optimized in any way? By this I mean, dpi reduced, number of colors reduced, etc…
Also, let’s say I have a HUUUUGE email chain. with a lot of replies. Any way to only fetch the most recent msg and use whatever was cached for the rest of the message (or fetch if it can’t be found).
(also agree with Opie)
Sam | 04-Dec-08 at 7:53 am | Permalink
I disagree with sending only the headers for all mail. As a former Blackberry user, I know how frustrating that can be. eMail should not be a chore, and you shouldn’t have to wait for it. You could, however, load the first 1 or 2k of the message body, and if it’s a long email, start downloading the whole thing *as soon as it’s opened* No getting to the end of the downloaded text and clicking a “more” option.
Ideas for identifying low-value email:
If you’re a BCC, it’s probably low value. There should be an algorithm to determine this, though, with a set of conditions like “If you’re a BCC and you open under 50% of emails on which you’re BCCed from this domain, set as low priority and only send header information and the first 500 bytes of body”
If the sender email is news@, newsletter@, listserv@, noreply@, info@, it’s probably low value. If the body contains the words “To unsubscribe”, it’s probably low value. But, like before, I think you need to analyze the user’s habits, too. Just because it’s a low value email doesn’t mean that the user doesn’t want to read it. I’m not sure how it works now, but if the peek can send a small ping back to your servers when an email is opened, that’d be very helpful in determining what is userful to them, and what’s not.
Offer filtering through getpeek.com. You bill it as a way for the user to cut down on junk on their device, and at the same time, you’re saving money on transfer. Through the web portal, allow people to say “No newsletters”, allow them to turn on a spam filter, or filter based on sender email, recipient email (for those of us who may have multiple addresses funneling into a single account), subject, etc.
Lastly, do a comparison with emails received by other users. You have the data (right?), so use it! If very similar emails are received by more than X users at the same time (or within an hour, or whatever), then it’s probably low value, especially if those users are not on the same private domain, do not share the same area code, don’t have zip codes within 50 miles of each other, etc, etc. The way that I would compare emails to consider them similar would be to first determine if the domain matches and is not a yahoo/gmail/msn/etc domain. Then out of message A pull a fairly long substring halfway through the email, and search for that substring in message B.
Sam | 04-Dec-08 at 7:55 am | Permalink
By the way– while you’re at it, why not add the ability to mark messages as high priority, and give them special notification on the device? And give low priority mail a special notification profile. As in.. “Don’t beep for low priority, beep for normal mail, and go nuts for high priority mail.”
Sam | 04-Dec-08 at 7:57 am | Permalink
Alright, last post.
If you want to save on bandwidth, put a calendar/to do list app on the device. You’re not doing yourself any favors making people outsource their scheduling and task lists to email.
David | 04-Dec-08 at 9:09 am | Permalink
While the header idea is great for most locations, I’m in a state with spotty coverage, meaning that I may receive an email while traveling and when I get to a place where I can read it, I don’t have coverage or poor coverage. If the email is already on the device I can read it, if the header is only there, I’m out of luck. Currently I receive some rather long emails, that when I don’t have coverage, I get to where the next bit needs to load, if I have no coverage I am once again out of luck until I do.
With all of this I have a question. Currently, how much of large emails intially is down loaded on to the peek?
porovaara | 04-Dec-08 at 9:25 am | Permalink
One of the more simple solutions to save yourself and the end user bandwidth; have a preference box for downloading headers only or all content for mime messages.
I consider all of my text emails, even long ones, to be high priority.
Nat Kramer | 04-Dec-08 at 10:51 am | Permalink
As a poster on one of the getpeek boards noted, there are a number of similarities between the Peek and the Kindle. The Peek makes a wonderful, lightweight e-reader, even where the text is not an alert or newsletter. This has obviously not escaped notice.
Perhaps the e-reader articles could be loaded onto the Peek via USB rather than by email. Peek saves bandwidth; the Peekster saves the need to wait to load later sections of his or her article.
Kitty | 04-Dec-08 at 11:04 am | Permalink
Here’s one way:
Allow for easy snipping of the quoted text in replys. Last night I got the ‘welcome to the crashtest pilot’ email. I replyed with some ideas for organization, but the whole message was quoted back.
I could’ve started a new email, but then it wouldn’t track as a reply, and there was no easy way to snip off most of the message. I seemed a waste at the time. I light of this post, it truly was a waste.
Billy | 04-Dec-08 at 12:18 pm | Permalink
why not just have a checkbox in the contact list to download or not download the full email from this contact. The ones that are checked as not, you could send only the headers with an option to download the full message. Helps you and makes the user experience faster and with less clutter. Now what the default should be? I guess header only? Lol. Just go ahead and give me a free month for helping you with such a perfectly simple solution… lol.
Opie | 04-Dec-08 at 4:15 pm | Permalink
Billy’s got a good point. You could then implement Sam’s algorithm idea to set the defaults for contacts. So by default every contact starts at “Auto”. Auto means that when a new user signs up for Peek service, and downloads their contacts, any news@ @listserv.* etc. type contacts are Auto-Off and all individual addresses are Auto-On. Then as you use the device, it looks at a sliding window of 2-3 months back to figure out which emails you’re likely to want to open.
For example, I think there are only about 5-10 contacts that I open every message and the rest I usually read back on my computer. I also look at anything that says “receipt” or “order” or “shipped” and never look at stuff with HTML formatting. Of course, exceptions to all those rules, but that would cut down on LOTS of data usage on my account.
CRAMSEY | 04-Dec-08 at 5:09 pm | Permalink
Let me start by saying today my peek reminds me more of a notify device. For example the notify service that displays on the bottom of the task bar when running outlook.
What I would like to see on the open screen would be:
[download button] [delete button] notification(s)
Hope the screen layout make since. What I’m looking to do is mimic how I use an email client on my desktop. 9 out of 10 times this gives me enough information on how to handle an email. If it is a large email or html based email I know it would be better that I find a pc where I can check my email versus trying to read the email on the peek.
The perfect solution would be a rich email client but due to various opportunities with the current peek design an architecture a rich notify client that enables you to “Peek” on your email has a lot of value also.
Maybe with version 2 of the peek, “peek email explorer”, many of the other issues related to a true internet device could be address that would allow you to view in html format, view pdf attachement, click on weblinks and launch a browser would be possible. Of course that version should be about the size of a tablet, have a touch screen and do all of this via public WiFi.
Sorry for ranting a little at the end. However, I was thinking about the limitations and if simplifying the device could result in a lower monthly charge I’m all for it.
Something like the ASUS 7″ Eee 8GB PC Netbook Computer with Linux – Pearl White
$269.99 from target basically fits the space of the rich internet email client.
I guess the perfect solution would be able to connect the two. Have a $10 a month basic email plan but then configure the peek in such a way that it could tether to laptops and have a ad-on plan that allows various levels of internet access.
Just my 2 cents.
amol | 04-Dec-08 at 6:00 pm | Permalink
These are such amazing ideas guys!
One hint — most of the bandwidth we use goes to “getting” messages. People do very little sending really…
Lewin A.R.W. Edwards | 04-Dec-08 at 6:35 pm | Permalink
How much complexity are you willing to add for the end-user, and how much coding can you do on the back-end?
My emails fall into four categories:
- Stuff from people in my contacts list
- Other email I want, and which I can filter by domain (eBay, my auto insurance company, my credit card company, etc), and which I usually don’t want to read while mobile, but MIGHT sometimes need to.
- Newsletters, which I’ll never read mobile
- Spam (400+ per day per email account)
Filter at the gateway. You could allow the user to manage this on the website, or learn directly from the device – click on an email, and select:
1. “Don’t read email from this person while mobile” (filters out this email address, won’t appear in the list of messages)
2. “Don’t fetch this email automatically” (filters email address on auto fetch, but a manual fetch can pull in the msg)
3. “Advanced” option which gives you wildcardable filters for the header, e.g “any header contains VIAGRA -> don’t download”.
(Pity you guys dropped out of the spectrum auction – this device would have been fabulous on a no-holds-barred network).
Joe Peregrin | 04-Dec-08 at 7:44 pm | Permalink
Initially, I’m not a fan of the downloading headers / only “first few of text” of the e-mail due to the latency and out of network issues.
As suggested by Lewin Edwards, I support the notion of a Peek device enabled spam list. For example, I receive promotional advertisements weekly from my grocery store and Redbox video rentals. I NEVER read them on the Peek because the e-mail only consists of hyperlinks to the HTML version of the e-mail. Perhaps the UI could be modded to add e-mail from these senders to a “no Peeking” list, a sort of Peek exclusive Spam list.
This “No Peeking” list would be set on my Peek and the list replicate on the Peek servers at, say, every other day. This way, the e-mail from the “No Peeking” senders could be filtered at the server and not forwarded over the cellular network.
Also, in my opinion including attachment images is a waste of transfer bandwidth. I don’t have the need to view every attachment that I receive in my e-mail inbox. This is not to say that I wish to do away with attachments. Perhaps the Peek servers may append every e-mail with an attachment that includes a ‘hyperlink’ (for lack of better word) to the attachment on the Peek server. This download link would then use the cellular network to retrieve the attachment from the Peek e-mail servers on request. Granted, the latency would increase when retrieving attachments; but this would almost be an expectation when clicking on a link to retrieve data.
Sam | 04-Dec-08 at 9:54 pm | Permalink
I’m still waiting on my Peek, so I don’t know how you currently handle HTML mail. Is it sent through with all the markup, and displayed ugly? Or do you strip it down on the server?
Lewin A.R.W. Edwards | 05-Dec-08 at 10:11 am | Permalink
Further to what Joe said, and to amplify what I wrote – I saw some interesting suggestions from earlier posters regarding algorithms and learning and so on. For the record, I’m very uncomfortable with heuristics of any sort deciding whether I should get or not get my email. I want whitelisting at the very least.
Face it – if it was possible to write a filter that would filter spam and other unwanted email 100% effectively, then we’d have no spam. The heuristic junkmail filters in apps like Apple Mail work pretty well, but they are definitely not perfect – they have a dangerous false positive rate.
Sam | 05-Dec-08 at 10:38 am | Permalink
Lewin– I certainly wasn’t suggesting that you not receive your email. I was proposing the use of heuristics to determine low priority emails– messages where you do not receive the entire body until you request it. And I absolutely agree– there should be both whitelists to set rules for messages that you always want to read, and blacklists to designate senders/domains/subjects/etc which you do not want to receive on your Peek at all.
Another idea for conserving bandwidth– drop any text that’s more than 1 or 2 quoting levels deep. (although there should be an option along the lines of “Some quoted text was omitted, download the full message?”
Same thing for messages where the reply is top-posted. (maybe also build an auto-reply nasty message to the top-posting sender?)
Steve Berry | 05-Dec-08 at 2:01 pm | Permalink
I would be fine with some way of ME indicating whether an email originator was “Low Value” and the Peek device learning that over time and not downloading messages for those unless I specifically opened them and waited
PhoneBoy | 06-Dec-08 at 12:49 am | Permalink
How about you use SMS to deliver parts of the email (say headers)? Is SMS cheaper for you than GPRS data? Probably not, but it’s a thought.
Steve | 06-Dec-08 at 9:11 am | Permalink
I think there are some great ideas here, but there is one thing I think is a must. Make a preferences page on the website where people can turn on/off or adjust the settings. What is good for one person could make the product useless for the next. We all use it for different reasons.
And don’t forget, your original base audience was for the non-geek, so if they never change their preferences because they want it to be simple, it has to leave all the functionality in place.
Lewin A.R.W. Edwards | 06-Dec-08 at 10:57 am | Permalink
@Sam – Just making the point that fuzzy logic is too problematic for me to trust it as an email filter. Explicit rules based on subject line, sender domain or other grep results – sure.
@Peek dev team – You know, it would be possible and very easy (I’m talking a weekend’s work here) to develop a proprietary compression scheme using a dictionary that’s *permanently* resident on the device side.
Essentially the same idea as tokenizing an interpreted language. Simple enough to have an n-byte token scheme, and put the most common words at the front of the token list so they’re all 8 bits.
Non-dictionary words can be escaped.
The device should ID its dictionary version to the server when performing the download so the server knows which tokens are supported and which words need to be escaped.
cramsey | 06-Dec-08 at 11:22 am | Permalink
I know this doe not fix anything. Would it be possible to ad a monthly bandwidth counter. Also it would be beneficial to see historical information on the website. Maybe even publicly display the top 100 offenders and average usage for the month as a way of peer pressure.
If the peek would be able to do only IM and sms messaging would we have a concern for bandwidth?
If the peek was only able to receive text based emails and all others where left in our mailbox except for the subject line would that solve the problem?
I am still a fan of simplifying the peek lowering the per month service charge.
Then enabling the peek to be tethered to other devices and having a prepaid program for that bandwith. In doing that I would like to be able to see how much bandwith I had remaing at any given time.
Oh BTW that concept would also be great to enable to peek for VOIP.
I am not sure whats possible with the current agreement but I think there is a lot of power there.
Maybe peek could partner with someone like vonage. The reason I say that is because vonage has a service that will convert calls to SMS messages then you could use there USB device to check your message or make calls.
Steve | 06-Dec-08 at 12:12 pm | Permalink
I think tracking people’s usage and putting it on-line is a very slippery slope. There are no limits set in Peek’s agreement and a person pays for the whole service and not for a certain bandwidth. To post someone’s name and their usage would open Peek up to a world of problems (potentially legal).
I don’t see peer pressure being a possibility. Again this is a paid service and how are the peer’s suppose to pressure someone? If Peek posts their email address, it is another no-no.
Ian Littman | 06-Dec-08 at 12:57 pm | Permalink
Cross-posted from Hackaday
I’m really curious as to whether this thing could get a bit of a speed boost by cleaning up code or whatever. Maybe get someone who worked for Palm a few years ago to work on the project…my old pre-OS 5 Palms ran great on even a 16 MHz processor. They even had a few models with color screens on 33 MHz procs…
A few other suggestions:
1. IM/text-via-IM support. Granted, it’ll take more battery power but it would take very little data to pull off and would net you guys tons more users. You could make a deal with Google, who already has the infrastructure in place, and AOL…so if you added a GMail or AIM/AOL Mail account you’d automatically have IM capability.
2. Push e-mail. Once IM functionality is in place, all you’d have to do is send an IM to the device when an email comes in, and the device downloads the email. Should use less power than polling for people who do’t get a lot of e-mail, too.
3. IMAP. I know, this creates issues with large mailboxes, but all you’d have to do is have a search function that will check to find certain messages, then pull them down as needed…
4. Archive option for GMail. With IMAP this is easy to do.
5. Quick-jump for emails. Search-as-you-type would be awesome and logical for something like this, but just typing in a letter to jump to an email would be much appreciated. I’m supposing there’s a “sort by” menu option anyhow so again logical progression.
6. PIM maybe?
With the above modifications to the device, the Peek could truly be a poor man’s BlackBerry. Sorta reminds me of the old days of Palm.net, except this device has a faster data connection than the pager-powered Palm VII, VIIx and i705 did. Lots of potential here, and honestly this is oe of the device types where a lot can be learned from Palm.
Looking forward to advancements as time goes on…
John M | 07-Dec-08 at 6:33 pm | Permalink
I get next to 0 low value email. Even mail that I wouldnt necessarily read on my computer, I like to read on my peek, including things like newsletters. I like reading email on the go, so I read more email than I normally do.
Furthermore, I get emails and often dont want to read them in places without cell coverage (train tunnels, certain places in my school) and I cant get the full text.
I’m anti this, but if its the only alternative to raising the monthly bill, then do it.
Opie | 07-Dec-08 at 11:47 pm | Permalink
I’m not suggesting that any control be wrested from the user, merely some defaults to the heuristics that are modified both by the usage of the device, and by manual settings by the user. For people like John above, the device should figure out pretty quick that you read nearly everything on your device, so it wouldn’t save Peek anything, but you’d have all your emails. For others, you could manually set, per email address, whether the email is always delivered, never delivered, or auto. Of course, there should be an email account-level setting that sets that as well. For example, my Comcast email is purely for awareness. I don’t really care what comes to that address, so I might set that account to never deliver, and it would just download headers.
Ian Littman | 08-Dec-08 at 2:29 am | Permalink
Just a quick tweak: make the “more message download” feature work “farther away” from the end of the message. Right now I find myself running into the “Getting More Content” (sic) notification. I’m fine with the Peek only downloading part of a message, but it needs to figure out that I’m going to read the whole thing by the time I’ve scrolled through 75% of the current material, not 90%. That way, it can seamlessly download the rest of the message via GPRS and not seem slow doing it.
Another tweak: quotes in replies. I get emails from my mom (in college and 800+ miles away) nightly or so and tend to reply to them inline, using what she says (insert “that’s what she said” here) and answer whatever mom-ish questions she has inline with the e-mail, marking my text off by a few dashes on a plaintext email device like my HTC Mogul or my Peek (yes, I’m carrying around both right now). Problem: the Peek only quotes the first little bit of an email in a reply. Maybe there should be an option for this?
Finally, if the Peek senses that coverage is dropping, it should grab full content of high-value e-mails, ones that tend to get read all the way through. That way, you’re not stuck with the first small portin of a message when you get out of cellular range.
Okay, one more thing…or two. Why not save a little data and improve the user experience by shortening links with something like bit.ly, tr.im or is.gd, and including them in text-format emails? That way, when you get to a computer and want to go to a specific link in an email viewed on your Peek, it’s a quick UR into the computer’s address bar and you’re there. Additionally, for long URLs it saves a few bytes, and you can tokenize the first thirteen or fourteen characters with no problem (http://is.gd/). So what was a, say, 75-character, 75-byte URL now becomes a byte-or-two token plus 4-6 bytes of characters. Or less, since URL-shortening services are case-sensitive alphanumeric (26 + 26 + 10 = 62, 6 bits) in their outputs.
Last: how much data does the average Peek user Tx/Rx over a month? Granted, it’ll be hard to find an average, but it’d give a better idea of what you’re up against, since you guys probably can’t tell anyone how much you’re paying per MB to T-Mobilefor transport (I’m assuming a per-user fee is also required).
Ian Littman | 08-Dec-08 at 2:34 am | Permalink
Okay, one final thing: why GSM?
1. Easier to port to other countries?
2. No royalty to Qualcomm?
3. Less power draw?
4. T-Mobile is cheaper?
Arguments for CDMA:
1. Higher speeds over 2G (1xRTT is the standard, and AFAIK is faster real-world than GPRS).
2. Sprint seems open to working with third parties on unbranded data services (Kindle), and Verizon now has an open initiative.
3. Better national coverage, especially with Verizon…especially with 850 MHz territory.
Lastly, any plans to put this device on WiMAX It would seem a perfect fit, once networks are rolled out. WiMAX would be fast, cheap, power-efficient, etc. so I gather. Like WiFi but o a much larger scale.
amol | 08-Dec-08 at 10:12 am | Permalink
@Ian Littman
You are right. Coming soon.