In the next weeks, I'll try to use the blog to announce a few things of Spybot - Search & Destroy 2.0, on topics where we would love feedback.
One important change in Spybot-S&D 2.0 will be that the functionality will be much more modularized. Not just one big .exe, but various smaller ones.
A few arguments:
Resources: you do not need everything Spybot offers all at the same time. By loading only those parts you need when you need them, Spybot can run faster, use less system memory, and on older 9x/ME systems, can use less of the precious GDI/user handles.
Speed: the app will simply show much faster.
Interaction: a challenge is to present it to the user in a way that is not affecting his ease of use; on the contrary, it should help him getting things done by presenting only that which he currently needs, at the same time allowing him to easily go to another part.
Updates & Maintenance: by having functionality separated, new functions or bug fixs mean that testing can concentrate on one module, and possibly those depending on it, but not on the full package, leading to faster and more stable updates.
Scripting/Scheduling: if you want to automate things, you can restrict that to the modules that offer the functionality you want to script, without the need to load the full, slow loading old app all the time.
The Modules:
Do you have any comments on other good or bad sides of htis approach? Let us know!
Finally, a few screenshots not really saying that much since the user interface question will be part of another blog post and will still receive more attention before becoming final: Settings, Quarantine, Immunization.
One important change in Spybot-S&D 2.0 will be that the functionality will be much more modularized. Not just one big .exe, but various smaller ones.
A few arguments:
Resources: you do not need everything Spybot offers all at the same time. By loading only those parts you need when you need them, Spybot can run faster, use less system memory, and on older 9x/ME systems, can use less of the precious GDI/user handles.
Speed: the app will simply show much faster.
Interaction: a challenge is to present it to the user in a way that is not affecting his ease of use; on the contrary, it should help him getting things done by presenting only that which he currently needs, at the same time allowing him to easily go to another part.
Updates & Maintenance: by having functionality separated, new functions or bug fixs mean that testing can concentrate on one module, and possibly those depending on it, but not on the full package, leading to faster and more stable updates.
Scripting/Scheduling: if you want to automate things, you can restrict that to the modules that offer the functionality you want to script, without the need to load the full, slow loading old app all the time.
The Modules:
- Main Scanner (actually two new modules, a new scanner librabry and its user interface)
- File Scanner (already known, improved by removal offer and some more features)
- Cleaner (actually various parts to improve the cleaning capability, but visible to the user in only one instance)
- Immunization (some may already know this from demonstration versions)
- Settings (with a lot of legacy options removed)
- Tools (the full capability as known from RunAlyzer, but sped up to have no waiting delay when opening it)
- Quarantine (formerly known as Recovery)
- Update (different from the 1.x one)
- Shredder (similar to how its already moved out now)
Do you have any comments on other good or bad sides of htis approach? Let us know!
Finally, a few screenshots not really saying that much since the user interface question will be part of another blog post and will still receive more attention before becoming final: Settings, Quarantine, Immunization.
